Il giorno lun, 14/08/2006 alle 20.55 +0200, Frans Pop ha scritto:
> Currently all packages producing udebs are in a permanently freeze state
> because:
Is this freeze manually handled by commands from RM? Within Britney
there is nothing strictly related to udebs, so I suppose it is handled
by hand.
> 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
I do not understand why Conflicts and Depends are not enough: any
pointer to a detailed documentation on how udeb packages work?
> 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.
>
> [snip]
If there is nothing which can detect a breakage of the d-i release, it
can't be handled in an automatic way so we have to deal with this
manually.
> 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.
The easiest solution for Britney would be to consider sources for udeb
packages as something indipendent from the source packages of the
traditional debs. Obviously, we can bind them so that the udebs can't
migrate before the real debs, but not the reverse.
> So, if we are going to automate udeb migration to testing we should:
> - do dependency checking for udebs for cases where dependencies _are_
> declared
That's ok.
> - 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
These are all things which are doable using hints and (maybe new)
commands already implemented in Britney.
Well, I'm quite confused at this point.. what about an IRC meeting to
discuss further these solutions? I'm not sure the email is the best
approach at this stage.
Thanks,
--
Fabio Tranchitella <kobold@debian.org> .''`.
Proud Debian GNU/Linux developer, admin and user. : :' :
`. `'`
http://people.debian.org/~kobold/ `-
_____________________________________________________________________
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564
Attachment:
signature.asc
Description: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio firmata digitalmente