On Wed, Oct 01, 2008 at 09:49:48AM -0700, Kees Cook wrote: > On Wed, Oct 01, 2008 at 05:11:23PM +0100, Roger Leigh wrote: > > Could you possibly explain what exactly you would like to do with this > > feature? I would be happy to add some general mechanism to sbuild, > > such as your patch, but I'd just like to understand the use case for it. > > Certainly. While I use sbuild for doing Debian builds, I tend to use it > much more for Ubuntu builds. Ubuntu has four components, defined in a > grid based on their freeness and commercial-supported-ness: > > supported unsupported > free "main" "universe" > non-free "restricted" "multiverse" > > In order to make sure that Build-Deps aren't satisfied crossing the > supported/unsupported and the free/non-free lines in the wrong direction, > I have to modify the source.list in the chroot before sbuild gets > rolling.
OK, thanks for the explanation. One easy solution here would be to have a different chroot for each variant e.g. unstable/main, but of course we need to use the chroot to get the sources, so this likely isn't viable. > So, yeah, I'm trying to imagine a general solution, but in this specific > instance, I need to know the distribution and the source package name > (from there, I can look up which component the src belongs to, censor > the sources.list and run apt-get update). OK. I think calling external scripts here would be a good idea. We could use run-parts to run all the scripts in e.g. /etc/sbuild/setup.d, for example, in a similar manner to the schroot setup scripts, but with all of the relevant sbuild state exported in the environment. This would make it trivially extensible by users and other packages. > > Would you prefer to have sbuild call an external program, or would > > enabling some sort of perl extension system using modules be acceptable? > > A perl extension feels like overkill, and I was thinking that an external > program (if it had access to enough of the sbuild state environment) > could be very easy to configure and change by an end user. Agreed. If you haven't already, you might be interested in looking at the current sbuild in git: git://git.debian.org/git/buildd-tools/sbuild.git Here, the main build state, configuration, chroot information etc. have all been object-oriented using perl objects. We can easily write a few lines of perl to dump the object state into the environment so scripts can access it. This would only be possible for scalar and perhaps array values realistically, but it would give you all you need to do what you want. This is unreleased; I was aiming to upload this to experimental this weekend, with unstable following the release of Lenny. Quite a few more changes are planned; the object-orientation is just the first step to getting a number of more significant changes made, including getting buildd into the Debian packaging and making wanna-build support multiple database backends, such as SQLite and PostgreSQL. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
