[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Unblock of packages in "could be handled by britney"

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:

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).


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: