Am Freitag, den 25.04.2008, 09:45 +0100 schrieb 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. Does debimg have to support versions before hardy, or can it drop compatibility with them? > > > 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. It will be some kind of a wrapper at python level. Maybe germinate could be modified to use apt_pkg's getCache and getDepCache, this would remove the need to parse source files in the germinate code. I'll see what I can do. > > (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.) Well, once the ubuntu changes are merged into debimg master, and Debian decided to switch to debimg, it will use > > > > 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. Well, once debimg is modular, you could easily hook this things into it, by creating a 'wrapper script' that imports libdebimg, registers some functions via something like libdebimg.hook and finally calls libdebimg.main(). > > 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. At the moment debimg only aims to replace the functionality for alternate disks, but let's add this feature. BTW, do you know about Debian Live's live-helper? Maybe the generation of live fs can be switched to the various lh_* scripts in live-helper. > > > 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. Actually, I was more or less talking about Debian CDs and debian-cd in general, as I find the configuration too complicated. > > 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. Let's see how far I can get. > > Cheers, > > -- > Colin Watson [EMAIL PROTECTED] >
--
Julian Andres Klode, Fellow of the Free Software Foundation Europe
Debian Maintainer | Developer | Ubuntu Member
try Debian: http://www.debian.org/ | my site: http://jak-linux.org/
jabber: [EMAIL PROTECTED] | IRC: juliank (FreeNode, OFTC)
languages: German | English
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-- 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
