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 [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
