Rethinking Ubuntu's Repositories

Mon May 24 15:27:22 UTC 2010

On Mon, 2010-05-24 at 09:01 -0400, Evan wrote:
> On Mon, May 24, 2010 at 5:08 AM, Conrad Knauer <atheoi at gmail.com> wrote:
> > I like the repository system that Ubuntu uses, but I feel that there
> > is a problem with it and I have a suggestion as to how to fix it.
> >
> > ~ The Problem ~
> >
> > Ubuntu inherited the Debian system of updating software versions with
> > OS upgrades.  This makes the most sense when you have many many
> > packages that are slow in updating (e.g. due to code maturity) and/or
> > you are upgrading your OS relatively frequently.  An example of where
> > this is a bad idea is Firefox, especially on LTS releases; an excerpt
> > from http://packages.ubuntu.com/search?keywords=firefox showing the
> > releases still supported on the Desktop:
> >
> > Package firefox
> >
> >    * hardy (web): meta package for the popular mozilla web browser
> >      3.0.19+nobinonly-0ubuntu0.8.04.1 [security]: all
> >    * jaunty (web): meta package for the popular mozilla web browser
> >      3.0.19+nobinonly-0ubuntu0.9.04.1 [security]: all
> >    * karmic (web): meta package for the popular mozilla web browser
> >      3.5.9+nobinonly-0ubuntu0.9.10.1 [security]: all
> >    * lucid (web): safe and easy web browser from Mozilla
> >      3.6.3+nobinonly-0ubuntu4: amd64 i386
> >
> > Most Firefox users have already moved to version 3.6 (see the graph on
> > http://gs.statcounter.com/#browser_version-ww-monthly-200904-201005)
> > which is where Mozilla wants you to be also BTW.  Getting a new
> > version of Firefox on an old version of Ubuntu can be a pain.
> > Supporting Firefox 3.0.x which is no longer supported by Mozilla (see
> > http://en.wikipedia.org/wiki/Mozilla_Firefox_3) seems silly.  PPAs are
> > unofficial.  Mozilla doesn't have a DEB repo and even if they do make
> > one, they might not offer packages other than for x86-32.
> >
> > ~ A Solution ~
> >
> > Now, assuming that there are no technical reasons why Firefox 3.6
> > can't be built for all the currently supported versions of Ubuntu, we
> > can do the following for future releases; get rid of the "main" repo
> > as it currently stands and replace it with two repositories:
> >
> > (1) a 'core' which will represent everything up to and including Gnome
> > (for Ubuntu; KDE for Kubuntu, etc.), so to a working GUI including
> > some basic apps (like Totem).  This is stuff that most users assume
> > will just work and don't want to fiddle with or upgrade for a while
> > once they're working right.  If Ubuntu is a 'software libre
> > supermarket', these are the canned, dried and frozen goods that have a
> > moderate to long shelf life.  This repo should retain the 'main'
> > designation.
> >
> > (2) the 'desktop' applications currently in main that people really
> > would like to stay current.  Especially Firefox, but also OpenOffice,
> > GIMP, etc. (that is, the 'big' ones (usually recommended by the
> > ubuntu-desktop metapackage, or otherwise in main) that aren't part of
> > Gnome proper...).  In the supermarket analogy, these are the big showy
> > fresh fruit displayed at room temperature.
> >
> > Perhaps a line in the sources.list could look like this:
> >
> > deb http://archive.ubuntu.com/ubuntu-desktop maverick main
> >
> > In 'main' cases like Firefox where you can have two versions that are
> > officially supported for a time, have a metapackage (e.g. firefox)
> > pointing at the newest release, but the actual versions in the names
> > of packages that contain data (e.g. firefox-3.5 and firefox-3.6).
> > This will allow users to pick if they would rather transition
> > automatically to the latest version or maintain the old version *while
> > it is still supported* (e.g. for businesses which tend to be slower in
> > adopting new versions... also, for people like my wife who bitterly
> > complain that new releases always break things... e.g. Firefox
> > extensions) since desktop software seems to have unpredictable release
> > cycles very much not in synch with Ubuntu's.
> >
> > In the case of Firefox (let's say starting in 2009 after Firefox 2
> > reached an end of life), my solution would work like this:
> >
> > - start 2009
> >
> > firefox metapackage points to firefox-3.0
> >
> > - June 30, 2009: Firefox 3.5 released
> >
> > firefox metapackage changed shortly to point to firefox-3.5
> > repository contains both firefox-3.0 and firefox-3.5
> >
> > - January 21, 2010: Firefox 3.6 released
> >
> > firefox metapackage changed shortly to point to firefox-3.6
> > repository contains firefox-3.0, firefox-3.5 and firefox-3.6
> >
> > - March 30, 2010: final version of 3.0 (3.0.19) released
> >
> > firefox-3.0 to be removed in a timely manner (a week or two?)
> >
> > - August 2010: final version of 3.5 to be released
> >
> > firefox-3.5 to be removed in a timely manner (a week or two?)
> >
> > - late 2010: Firefox 4.0 (hopefully ;) releases
> >
> > firefox metapackage changed shortly to point to firefox-4.0
> > repository contains firefox-3.6 and firefox-4.0
> >
> > etc.
> >
> > ~ Misc. Thoughts ~
> >
> > Splitting out the desktop apps would mean that old LTS releases (like
> > Dapper, which is expired for the desktop but still supported for the
> > server) would not need to keep ancient browser packages around (like
> > Firefox 1.5)!
> >
> > There are some notable 'desktop' apps in Universe (e.g. VLC, Chromium
> > (chromium-browser), Thunderbird and Wine spring to mind), which are
> > under active development and could be treated similarly...  Perhaps
> > "deb http://archive.ubuntu.com/ubuntu-desktop maverick universe" ?
> >
> > Sincerely,
> > Conrad Knauer
> 
> This idea has been raised before in various forms.
> 
> See http://www.mail-archive.com/ubuntu-devel-discuss@lists.ubuntu.com/msg02743.html
> 
> I suggest you read through to the end of the thread, since a lot of
> good points are raised on both sides.
> 
> I'm not against the idea, but there are still some obstacles to overcome.

I think the most important thing is to leave the choice to the users.
Some of them will want to upgrade to the latest and greatest; others
will want to stay with what they know; and others still will want to run
both old and new side by side until they are confident that there are no
regression in the new version.

In practice, that's exactly what the planned functionality for
delivering apps post-release in Sofware Center 3.0 is meant to address.
Have a look at the blueprint [1] and the full spec [2].

[1]
https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-opportunistic-apps-stable-release
[2] https://wiki.ubuntu.com/PostReleaseApps

Bruno