Full support of udebs


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

{{{Hi,

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.

Right.

> 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

-- 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.

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