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

[RFC, LONG] Proposal: DAK - automated migration of udebs



(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: pgpkzI0kEFzDM.pgp
Description: PGP signature


Reply to: