(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
because:
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
removals.
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_
declared
- 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"
packages
- 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
testing)
- 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:
http://merkel.debian.org/~joeyh/d-i/testing-summary.html
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.
Cheers,
FJP
Attachment:
pgphOHspr3pSl.pgp
Description: PGP signature