[maemo-developers] Repositories mess: conclusions and actions

[From: Graham Cobb]

On Sunday 11 November 2007 22:32:53 Nick Phillips wrote:
> On 12/11/2007, at 11:21 AM, Graham Cobb wrote:
> > I don't think I agree.  I am concerned about what will happen when
> > V4.1 is
> > issued.  For Bora I currently build my packages against 3.0 so that
> > all
> > releases of Bora can be supported.  I would expect that the same
> > thing would
> > happen with Chinook: packages should normally be built against the
> > oldest
> > libraries that will work and which do not conflict with the latest
> > libraries.
> > Otherwise users may experience unexpected (and partial) upgrades of
> > base
> > system components due to installing an application.  Will Nokia
> > test all
> > possible combinations of partial OS upgrades when 4.1 comes out?
> >
> > This is a complex issue which also requires some further thought
> > from the
> > point of view of autobuilder requirements.
>
> As I wrote a while ago, I'd recommend people interested in this check
> out Debian policy (http://www.debian.org/doc/debian-policy/) and
> Ubuntu's equivalent (not sure where you'd find that), and see how and
> why Debian and Ubuntu deal with these things. There are differences
> (e.g. Debian requires a binary on one arch to be uploaded, while
> Ubuntu allows/prefers autobuilding for all), but there should also be
> some issues that are pretty firmly resolved one way or the other.

Checking out major distributions' policies is a good suggestion but this is 
one particular area where I think Maemo is likely to diverge from Debian.  
This is because there is a commercial company supporting the OS.

Let's assume, for a moment, that Nokia introduces a V4.1 that updates both 
libhildon1 and libhildonfm2 to new versions.  I presume Nokia would test the 
old versions of the libraries together, and the new versions of the libraries 
together but would not expend testing effort on testing the new libhildon1 
with the old libhildonfm2.  And assume that there is actually a bug and the 
old libhildonfm2 doesn't work correctly with the new libhildon1.

If a user does a dist-upgrade they will get both new libraries, so no problem.  
However, if the user installs an application which is built against the new 
libhildon1 (but which doesn't use libhildonfm2) then the AppMgr will kindly 
install the new libhildon1 without the new libhildonfm2.  Which would create 
a configuration never tested by Nokia and could break existing 
(Nokia-supplied and supported) applications which use libhildonfm2.

Debian doesn't have this problem.  The stable release is a single unit and 
doesn't get any upgrades (except security fixes, which are very limited and 
tested carefully).  If a problem like the one I have described occurs in the 
testing release the affected user would log a bug or send a request to a 
mailing list or forum and (eventually) be told "this sort of thing is a fact 
of life using testing: just install the latest libhildonfm2".  

So, we need to ask Nokia what they want to do about this case.  My suggestion 
is that the autobuilder would always build against the oldest releases of the 
libraries (the oldest release with the same codename: so the oldest chinook 
release in my example) so that no partial upgrades would occur just from 
installing a package.  Alternatively they may be able to make all the files 
in a release depend on some particular version of a pseudo-package and have 
that depend in turn upon all the packages which form that release, so if one 
package got upgraded they all would.  This still has the disadvantage that 
installing a (possibly tiny) application could suddenly trigger a full OS 
upgrade when you are not expecting it.

Graham