(Reply-To set to debian-release) Last year Fabio Tranchitella did a python rewrite of britney. The last open issue AFAIK is the support for automated migration of udebs from unstable to testing. This has been discussed before [1], but the subject got parked until after the release of Etch. The proposal is for what I see as the best possible solution. It implementation is probably also the most complex, but it also brings the highest possible degree of automation and prevention of unexpected breakage of a current D-I release. Less complex solutions are probably possible, but will IMO mean a lot more work for RMs (both Debian and D-I RMs) in the long run. Everything below (including the requirements) is of course open for discussion. Cheers, FJP BACKGROUND ========== Currently all packages producing udebs are frozen by a (manually maintained) list of blocks and unblocked manually if they need to migrate. The migration itself requires manual action (done mostly by jvw; supported by scripts) and is only done after the source and debs have already migrated. Migrating packages providing udebs is a bit more complex than migrating regular packages because they have the potential of changing and, more importantly, breaking the current release of D-I in testing. This is further complicated by the fact that it is (at least currently) not always possible to define (versioned) dependencies between udebs. The only area where dependencies can be relied on is for dependencies on libraries. In this context, the following categories of udebs can be distinguised: 1) udebs that can always always be migrated safely These include TTF font udebs and udebs for e.g. beep, eject, nano, dhcp-client, openssh, etc. 2) udebs that, although incompatible with the current D-I release, can be migrated without breaking it because they are always contained in the D-I initrds at build time and not loaded from the archive at run time These include some udebs from libraries like gtk, cairo, pango. 3) udebs that can normally be migrated safely, but can occasionally contain changes that break a current D-I release These include utilities like mdadm, lvm2. 4) library udebs that are loaded at run time and would break the current D-I release if there are incompatible ABI changes These include mainly libc and libraries used during partitioning, such as udebs from parted, e2fsprogs, etc. 5) udebs for main D-I components (mostly maintained by D-I team) Especially here the problem of not being able to specify dependencies and conflicts is relevant. This is also where migration is often not desired because it would change the functionality of the current D-I release (in the case of components loaded at run time). REQUIREMENTS ============ - migrations should not break the current D-I release - migrations should be automatic as much as possible - dependency checks should be automated as much as possible - more control over migrations should be possible when a D-I release is being prepared PROPOSAL ======== An initial idea was to allow udebs to be out-of-sync with the source in testing (i.e. allow source and debs to migrate earlier than the udebs). This idea was vetoed by Steve Langasek for release management reasons and general quality considerations. The consequence of this is that some packages will remain blocked from migrating to testing if doing so would break a current D-I release. General concept --------------- The implementation for DAK proposed below is based on the following principles: - blocking for udebs should be separate from regular blocking as they are done for separate reasons by different people - packages with udebs are frozen by default; packages will not migrate unless their udebs can migrate as well - dependencies should be checked where possible, mainly because this would make category 4 a non-issue (or at least, not require any attention from RMs) - permanent hints to allow migration will be set where possible, i.e. for category 1, 2 and 4 (4 only if dependencies are checked automatically); these hints can be disabled when a D-I release is in preparation - in all other cases a hint is required, i.e. categories 3 and 5 Changes in DAK -------------- This proposal does not include proposals for technical implementation, just the concept. Fabio is better placed to propose possible technical implementations. I Dependency checking for udebs With a few exceptions, udebs will always depend on other udebs. The most relevant exception is libc, where the dependency is still on the regular package. This would need to be worked around util we can fix that. II Migration of udebs together with source and debs III Default blocking for packages containing udebs IV Support for new hints As migration of udebs will be blocked by default, the following hints would be useful to manage migrations: - allow-udeb <package> Allow any version of the package to migrate if there are no other blocks and (udeb) dependencies are met. These would be the "permanent" hints mentioned above. - unblock-udeb <package>/<version> Allow a specific version of the package to migrate if there are no other blocks and (udeb) dependencies are met. Intention is to set these hints early so packages will often be able to migrate normally. - unblock-udeb-all (optional) Having this hint could be useful in the period just after a stable release (as now) when there are many changes in the archive and blocking migrations because of udebs doesn't really make any sense as there is no current D-I release in testing yet. Hints could be set by any RM (assistant), but I would suggest making the D-I RM (and backup) a release assistant and allow him to manage these hints as he will have the best understanding of which udebs can and cannot migrate without breaking the current D-I release. Of course with the understanding that he should not do normal hints. Other changes ------------- The changes in DAK will probably also necessitate changes in other services like bjorn.haxx.se and the PTS so that the reasons why packages cannot migrate are correctly displayed. The "udeb testing summary" [2] should be extended to show the hint status. [1] http://lists.debian.org/debian-release/2006/08/msg00164.html [2] http://merkel.debian.org/~joeyh/d-i/testing-summary.html
Attachment:
pgpomBOaJKT19.pgp
Description: PGP signature