On Friday 04 April 2008, Frans Pop wrote: > Note that this still only one reason why we need the acks. Preventing > breakage is the other. Actually, the current klibc migration is a very nice example of this, so let me elaborate. Yesterday we had the following message and commit: http://lists.debian.org/debian-boot/2008/04/msg00112.html http://svn.debian.org/wsvn/d-i/trunk/packages/rootskel/?rev=52409&sc=0 Note that the dependency was undeclared (a minor bug) and is now still unversioned (as I don't know the reasons I cannot explain them), so ensuring rootskel and klibc are kept in sync needs to be done manually. So, rootskel and klibc should migrate together. That means we need to look at other changes in rootskel. rootskel 1.59 includes changes required for D-I to work with busybox 1.9.1-3, but those changes will break with older versions of busybox (again this dependency is not declared, just noted in the changelog), so that ties busybox together with rootskel and klibc. Let's look at busybox 1.9.1-3. That dropped the ifconfig command in favor of the ip command. We still had a few components that used ifconfig (network-console, installation-report and ppp-udeb), so those should all migrate together with busybox; in this case the new versions will also work with the old busybox. But ppp-udeb has not yet been updated. There's also a mild regression in busybox 1.9.1-3 for the pidof command (#472846) for which a workaround was added in finish-install, so add that in the mix. Now, luckily currently all these 4 components don't have changes that require additional updates, so it ends here. Note that in all these cases the dependencies are undeclared and that both busybox and klibc are in the "could be handled by britney" class. So, why did we not object to the migration of klibc? - it does not break the current release of D-I because both klibc and rootskel are included in D-I initrds at build time - we don't do new builds of D-I based on Lenny, except for new releases - there probably are others who _do_ build D-I based on Lenny, but as this only affects floppy-based installations and migrating klibc is way more important than that, we allow it anyway; it's a trade-off The same goes for migrating busybox: it's always included in D-I initrds, so migrating only busybox will not break the current D-I release. However, in this case the breakage for new builds is much more severe (as it affects all installation methods, not just floppy installs), so we probably _will_ want to migrate the related D-I components to Lenny at the same time. I hope this extended example demonstrates sufficiently why I feel that all migrations of udebs should be acked by the D-I RM. And that it also demonstrated that the category "could be handled by britney" is a bit more complex than the name implies. If proper britney support was implemented there _are_ some udebs that could be done completely automatically, but there will always be cases where automated checks are insufficient. At least until we completely rework the dependency declarations in udebs (which would also require adding support for Conflicts). Cheers, FJP
Attachment:
signature.asc
Description: This is a digitally signed message part.