Debimg for Ubuntu Intrepid Alternate Disks?

[Colin Watson]

On Thu, Apr 24, 2008 at 10:50:14PM +0200, Julian Andres Klode wrote:
> Am Donnerstag, den 24.04.2008, 20:45 +0100 schrieb Colin Watson:
> > Somebody would have to replace this with germinate, or else merge the
> > appropriate code from debimg into germinate; it's not a good idea to
> > diverge different bits of the distribution on something this
> > fundamental.
> 
> Can it be used directly from within Python, as a package (via import)?

Yes; the interface has been known to change, but I expect I'd keep such
changes more minimal once there are external users. /usr/bin/germinate
is a fairly thin wrapper over the internal logic.

> I want to have a function which returns all the packages to be added.

It will be necessary to translate the logic from
http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ that we're
using at the moment. The relevant scripts are run-germinate and
germinate-to-tasks, and the various things they call. Before 8.04, a lot
of specific details for various flavours were hardcoded; now most of
this is driven by the inheritance information in the seed STRUCTURE
file, and the scripts just follow it.

> debimg uses apt.cache, which is a bit higher level code, and allows
> debimg's code to be really small (it's actually no good code, as there
> are even no version number checks [disks could break]).

You mean versioned dependencies? Germinate doesn't handle those either,
unfortunately, although it's been on my to-do list for a while
(https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/74514).

> I will take a look at the germinate code and modify the debimg code to
> use the same algorithms (or create the same result).

I'm definitely not looking for debimg to duplicate germinate's code;
that doesn't really help us at all. I'm looking for it to actually use
germinate. The Ubuntu archive uses that too, and precise consistency is
important.

(Germinate is available in Debian too, and its logic isn't specific to
Ubuntu, other than the fact that its defaults currently point to Ubuntu
seeds because I'm not aware of well-maintained Debian ones; if Debian
started using seeds for its CD building then that could change.)

> > What are the advantages of this over our current system? So far, it
> > sounds like there are at least some regressions (support for
> > architectures other than amd64/i386, and almost certainly the need to
> > port all our painstakingly-developed customisations to it); what would
> > we gain to make this effort worthwhile?
> 
> debimg is developed in one language and calls almost no external
> programs. It should also be faster than debian-cd, though I can't check
> this. I don't know about the exact build system and the modifications
> made to debian-cd, are they available somewhere?

Sure:

  http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/
  http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/

I consider the fact that the germinate logic is in cdimage rather than
debian-cd to be a wart, by the way, and similarly for things like logic
for which archive components to use. Ideally, I'd prefer all that to be
in debian-cd (or debimg), and for cdimage to be simply a wrapper that
deals with updating the mirror, kicking off builds, and publishing the
results.

Similarly, there's no way to easily build live CDs from scratch at the
moment; you have to separately set up livecd-rootfs and have cdimage
fetch the output. This is of course what you have to do for
multi-architecture builds, as you need a buildd of the appropriate
architecture to build the filesystem image, but it would be awfully
convenient to have a quick way to build the whole thing for your current
architecture.

> My goal with debimg is to support the creation of Debian and Ubuntu
> disks, therefore I will add needed features anyway. There won't be much
> work left on Canonical's side, once I integrated the features. debimg
> will also get support for more architectures in the next version, and a
> generic "framework" to add new architectures. It will also be able to
> directly use the python-libisofs bindings I develop to create ISO
> images.
[...]
> > I'm no enormous fan of debian-cd, understand, but it sounds like a lot
> > of work to shift over to anything else too.
> 
> BTW, I never got a working build with debian-cd. If you tell me what
> changes are needed, I'll make them.

At the moment, I expect that the only working way to produce Ubuntu CDs
is to use the code available from the bzr branches above. I acknowledge
that it's a bit hard to set up, and that fixing that would be a win for
people other than our own CD team who want to create CD images.

It sounds like it's a bit early yet to talk about cdimage.ubuntu.com
switching over to this; this is critical infrastructure and needs to be
stable, even during the development part of a cycle, so that other
developers can get their work done. However, if you're keen to port
Ubuntu customisations into debimg, we might well consider switching in
the future once all that's a little more in place.

Cheers,

-- 
Colin Watson                                       [cjwatson at ubuntu.com]