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

Re: udeb support for britney

(as discussed on IRC, CC'ing debian-release as others should be able to 
comment; please reply to the list)

Hi Fabio,

First of all, thanks for contacting me on this and nice that this subject 
is getting attention.

Note that my knowledge of the archive scripts and procedures is limited, 
so I'll welcome any corrections to what is written below.

On Friday 11 August 2006 13:42, you wrote:
>   sorry for the disturb. I'm working with Andreas Barth on a python
> rewrite of britney. One of the features Andi asked me to implement is
> support for udeb, but according to him you are the right person to
> discuss with the implementation.

Currently all packages producing udebs are in a permanently freeze state 
1) the archive scripts do not support automatic migration of udebs
2) in some cases migration of a udeb can break the current release
   of the installer in testing (currently Beta 3)
And also:
3) automatic migration of udebs is also complicated by the fact that
   dependencies between udebs are not (and cannot) always expressed
   in Depends: and Conflicts: relationships (this is part of the
   relaxed policy requirements for udebs); fixing this would require
   introduction (and support in archive scripts) of new fields in the
   control file

The second and third issues are true for both updates, new udebs and 
So, supporting automatic migration of packages producing udebs without 
taking into account 2) and 3) would actually be a regression from a d-i 
release management point of view.

Breakage of a d-i release can take many forms, not all automatically 
detectable. Some examples:
- ABI change in a library
- changes in behavior in commands in busybox (example: a recent busybox
  update deprecated 'tail +2' which was used in d-i)
- renaming of an udeb

Another aspect of udeb migration is that, from a d-i point of view, in 
most cases it would be no problem for source packages producing both debs 
and udebs ("mixed" packages) to migrate the source and debs, but to hold 
back the udebs.
An important question for the design of a solution is how acceptable it 
would be to have source and udebs out of sync in testing between d-i 
releases. Of course, for a stable release everything must be in sync, but 
IMO we can easily manage that.

Of course, for packages that only produce udebs, the source should never 
migrate without the udebs. And conversely, IMO a udeb should never be 
allowed to migrate if the corresponding source package does not migrate 
at the same time or has not already migrated.

IMO, the inconsistency is acceptable given the definition of testing as 
"the suite where the next stable release is being prepared"; maybe the 
archive scripts should make sure that the source for "out of sync" udebs 
is not deleted from the testing archive to satisfy GPL requirements.

So, if we are going to automate udeb migration to testing we should:
- do dependency checking for udebs for cases where dependencies _are_
- allow for a list of udebs that should never migrate automatically
- allow for specific blocking of udebs if a new version is known to
  break testing
- possibly automatically require hinting for cases that are likely to
  break testing, like new upstream versions
- possibly allow for a list of udebs that can always considered safe
  to migrate automatically (like fonts)
- possibly send warning messages for udebs that are about to migrate
  so a check can be done 

However, that gets very complicated as it is based on handling loads of 
types of exceptions.

A much simpler solution would be possible if having udebs out of sync with 
source would be structurally allowed between d-i releases:
- separate migration of 1) source and debs and 2) udebs for "mixed"
- use normal migration rules for debs and source for "mixed" packages,
  ignoring udeb dependencies;
  (RC bugs can be filed to hold back regular debs that would break d-i in
- always require hinting for udebs (d-i RMs should probably be authorized
  to do this themselves); d-i RM would be responsible for not
  unnecessarily keeping udebs out of testing for too long
- if a udeb-hint is already in place for a "mixed" package when that is
  ready for migration, the udeb should migrate at the same time
- nice features to simplify udeb-hinting would be
  - udeb dependency checking before migration (disallowing migration if
    a hint for a dependended on udeb is missing)
  - an exception list for udebs that are safe to migrate automatically

We already have a page that could probably be extended to manage hinting:

For any solution an easy way to freeze _any_ package producing udebs would 
be very nice to have. That would allow to prevent unwanted migrations and 
prevent source/debs and udebs getting out of sync when actually preparing 
a d-i release.

I think that is enough food for thought for now.


Attachment: pgphOHspr3pSl.pgp
Description: PGP signature

Reply to: