Differences between revisions 6 and 7
Revision 6 as of 2007-05-16 11:34:46
Size: 4845
Editor: ?FransPop
Comment: Add link to new proposal
Revision 7 as of 2009-03-16 03:31:16
Size: 4847
Editor: anonymous
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 93: Line 93:
  --["Jeroen"]   --[[Jeroen]]
Line 95: Line 95:
New [http://lists.debian.org/debian-release/2007/05/msg00086.html proposal available] on the debian-release mailing list. New [[http://lists.debian.org/debian-release/2007/05/msg00086.html|proposal available]] on the debian-release mailing list.

Full support of udebs

  • Mentor: LukClaes (jvw: add yourself here if you're proposing yourself as a mentor)

  • Summary: The goal is to make sure that no special manual intervention is needed for testing migration of udebs

  • Required skills:

    • python
    • C/C++
  • Description: udebs are Debian packages that are stripped down to be really small to be able to use them in debian-installer. Currently there is a manual intervention needed to make sure udebs and their source and deb equivalents are in sync.

I wrote to jvw about this project and am "forwarding" his reply. In summary he does not believe that this alone would be an appropriate Google SoC project. -- FilipusKlutiero


Feel free to forward this to luk, btw.

On Tue, Mar 20, 2007 at 11:10:30AM -0400, Philippe Cloutier wrote: > Hi Jeroen, > I'm aware that updating udebs in testing is currently complicated from > following IRC and debian-release. The Google SoC project proposed by luk > sounds interesting for me. I discussed that with luk a bit, and he made > me realize that this could be more than hacking on britney. The problem > is that very few people know how things are working currently so it's > difficult to do a reasonably-detailed application for this project.


> Therefore, I would like to know a bit about: > what work would this project save? ; what are you doing currently with > udebs, and how would the project change that? would the project save > work to other people?

Currently, the work it'd save is not extremely significant. There is a method with scripts that semi-manually sync udebs of a source package from unstable to testing. It involves invoking a command, which basicly does all the necessary checks, and then confirm it.

I'm currently the only person doing so, mostly excusively on request of fjp, or as triggered by the consistency checking script run from my crontab (output: http://ftp-master.debian.org/~jeroen/d-i.out)

> how much time (a year?) would that save you? > which software other than britney needs to be touched significantly? > do you think this would make an interesting Google SoC project? > particularly, does the time (12 weeks) seem too much or too few?

I think the solution would be pretty simple. Making sure that udebs get synced along with regular debs, by having them fed to britney as input -- britney would already deal with it properly if the udeb package lists would get properly mangled. 12 weeks would really seem (way) too much for that, to be honest -- it's not really that complicated, new, or special, it's "just" a bit of grunt work getting it to work proof-of-concept on your own system, write a proper patch with appropriate shell/python magic, and getting it applied.

Implemented this way, udebs can be controlled by the release team much like (or exactly like) any other source package.

> do you volunteer to mentor this project?

I would, if I'd see something significant to do in this area. Personally, I don't think udeb handling in britney is that, it'd need to be something more. No, I don't have any specific suggestions at the moment.


-- Jeroen van Wolffelaar Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl }}}

Note that this is an open issue from last years summer of code when Fabio Tranchitella worked on Britney that we have decided (for different reasons) to park until after the release of Etch. The intention from Fabio and me is to pick this up then.

  • I agree with Frans: this is the natural follow up for the work I started last year. I do not think that this is a project suitable for SoC. -- Fabio Tranchitella

It is probably not extremely difficult, but still needs very careful implementation as the D-I release manager needs to be able to determine which packages containing udebs are allowed to migrate and which not as udebs have incomplete (versioned) dependency information and thus uncoordinated migrations can break an existing release in testing.

-- Frans Pop

  • Don't the current 'block' stanza's in hints file provide adequate control? What control would you like to have beyond that? Also for lenny, I think in the latter half of the release cylce you'd want to block most if not all udeb stuff, by having britney deal with udebs just like debs, it can be done completely by RM, udebs will always just follow source packages, and britney will make you use force-hints if dependencies wouldn't otherwise allow a migration/the package is out-of-sync on some architectures.


New proposal available on the debian-release mailing list.

-- Frans Pop