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 _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
