Idea #11154: Make packages in Ubuntu repos more up2date

This idea is a duplicate of idea #2117: Make latest version available.

Written by ilembitov the 15 Jul 08 at 12:29. Category: System.
Related to: Nothing/Others. Status: New

Description

First of all, here I mean only the user apps, like browsers, mp3players, etc. Not system components like kernel or alsa.

I understand Ubuntu's community concern about stability. That's an important point why Ubuntu doesn't get major updates to software included in current Ubuntu release. But I guess, I can suggest a way out.

As you might know, Ubuntu repos are divided the following way:
-main: the apps that are thoroughly tested since they are included by default and are percepted as important components of Ubuntu distro
-restricted: components that simply can't be supported by Ubuntu community, since they are proprietary software
-universe: packages that are being maintained by 3rd party, not officially supported by Ubuntu community itself.
-multiverse: non-free pieces of software

As you can see, only the components included in "main" are officially supported and thoroughly tested. My point is, why not offer more frequent updates to components in other repos? Say, Banshee, an interesting and relatively popular mp3 player got a final 1.0 release recently, featuring many improvements over 0.13 version which is in Hardy repos. And, this package is in Universe, so users don't get any guarantees from Ubuntu project anyways. Then why not update it? Just to the version that the original package devs consider to be stable. Or wine, which got a long-awaited 1.0 release. Why users should wait for months to get an update to a package that isn't supported anyways?

Another point, is that there are some packages in main repo, that need updates, but can't get them again due to policy. But there is backports repo! Following Debian tradition, backports include fresher versions of apps without updating system-critical ones. For example, transmission in main has version 1.06. Actually the latest version is 1.22. And it also has vital changes: better multi-tracker support, etc. And they are actually really important. So why not include it to backports?

So, to sum up, my suggestion is to update apps in backports and all repos (besides main) more frequently to keep up with other distros (Mandriva, OpenSuSE).

Tags: banshee repos software transmission updates

Attachments

No attachments.

Duplicates

[Report a duplicate and merge its votes to this idea]

Comments

Ssdg wrote on the 15 Jul 08 at 13:40

update apps in backports: why not.
update in other repositories: no. (they are tested by the packager (it isn't an easy and short job)) so let the packager work on the next release or his project and if you want to use backports, why not, but non-security/bug updates dont have to be in the other repositories.

-1

ilembitov wrote on the 15 Jul 08 at 13:52

Other repos aren't really quality driven. They aren't guarantied to have tested and stable packages. There are many dead or buggy packages there. But furthermore, they are out-dated. That's why projects like getdeb.net are pretty popular - users need fresher software. So I don't see any time consuming job of maintainers here. The point here, is that their work shouldn't be tied to release schedule: they should test and add new versions as they appear on official sites. Besides: please tell me, why Mandriva or OpenSuSE project are able to deliver fresher apps, and Ubuntu is not?

Exsecrabilus wrote on the 15 Jul 08 at 14:10

If packages were updated like you mentioned in your description, then what would be the need for distribution releases? Everything could be updated to the latest version, then what happens to the joy of awaiting a new release? If you want a rolling-distribution release, go for Arch; That's a good Linux distro.

ilembitov wrote on the 15 Jul 08 at 14:16

Distribution release offers a thoroughly tested snapshot of MAIN repo, not all the repos. The other repos are the same tested as Arch's, just oldier

chipbennett wrote on the 15 Jul 08 at 16:40

-1

Isn't this idea the very reason for the Backports repository?

Ubuntu's MO is for packages to be tested for stability against a certain Ubuntu release version; thus, each release (Hardy, Gutsy, Feisty, etcc.) has its own set of repositories (Main, Uni, Multi, etc.). The packages in those repositories *only* get security/critical updates.

The Backports repository for each release version (e.g. Hardy-Backports) is used for more-current, non-security-updated packages.

This scheme seems to work as intended - especially considering that Ubuntu releases every six months, thus the *current* repositories are refreshed every six months.

ilembitov wrote on the 15 Jul 08 at 16:51

2chipbennett
First, explain to me, what's the point in all those restrictions laid upon repos that aren't actaully tested and supported. Do they get better just by lying there for half a year?
Second, the scheme DOESN'T work, since most other distros (again, user-friendly distros like OpenSuSE or Mandriva, not things like Slackware or Gentoo) offer fresher software, although most distros have six-month release cycle these days.

chipbennett wrote on the 15 Jul 08 at 16:59

@ilembitov:

Perhaps I am mistaken, but it seems that you have an underlying assumption, that "fresher" packages equal "better" packages.

That assumption does not always hold.

Also, updated packages may also have updated dependencies. Updating those packages in the repositories would then require also updating the packages upon which they are dependent.

But, *other* packages may also be dependent upon those same packages that were updated in order to support the first updated package. Those *other* packages may not support their dependencies being updated.

Thus, the six-month release cycle allow for all of those package-dependency issues to be resolved at one time.

I'm no package developer/maintainer, but I would imagine that the dependency maintenance for the packages in a given repository is a non-trivial activity.

Thus, that activity would require either time or (developer) resources that Canonical have decided are better-spent on development of the next up-coming release.

Personally, I agree with that decision.

Post your comment