On Wed, Dec 15, 2010 at 04:36:46PM -0500, Sam Hartman wrote: > When --setup-hook was implemented in terms of --chroot-setup-commands, > the user it is run as changed. Previously it was run as root; now it is > run as the build user. > > That's problematic because there no longer seems to be a way a to run > commands as root in the chroot.
Yes, this looks like a regression, and we'll fix that so this continues to work for you. We might need to have setup commands that run as root, and some as non-root. I'll discuss it with Andres Mejia, who wrote these features. > My use case is as follows. I'm building a related set of packages that > inter-depend on each other under the control of a buildbot. The build > slave (which runs sbuild) doesn't have the permissions necessary to > install into any apt archive. So, I want to modify the chroot to have > an additional apt source. The location of that source will depend on > which build slave it is, and so I'm running a setup hook to do this. You might like to look at the most recent sbuild in unstable (or git). We create a local apt archive during the build (when using the apt or aptitude build-dep resolvers) and set this up and use it. These are ephemeral (they only last for the duration of the build), but the logic to do the archive setup could be reused to do what you want. We only use it to serve a couple of packages, but it might be useful for your uses as well. See (setup|cleanup)_apt_archive in lib/Sbuild/ResolverBase.pm. Even if you aren't using the archive, the logic to add/remove entries from /etc/apt/sources.list.d is there. Also, take a look at etc/99builddsourceslist. This is used on our buildds as a schroot setup script to customise the apt sources for security/volatile/backports/proposed-updates etc. This might be closer to what you want, though you can probably make it simpler! > I'd be happy with any of the following options: > > * external commands run as root > * a way to do a build in a session style schroot (schroot -r -c > * session:foo instead of schroot -c foo) This /might/ be possible, but I haven't tested it. You could try running the above to see what happens, but I can't guarantee happiness. It will probably always try to begin a session, and that's where it would fail. We could add logic to skip chroot setup/cleanup if given a session, which should allow this to function; we would need to be sure it cleans up correctly though (a clonable chroot would normally skip it). > * A way to make packages of my choice available for satisfying build > * depends Are you aware of the add-(depends|conflicts)[-indep] options to do this? For example, --add-depends='foobar (>= 4.5-2)'. Not sure this would be appropriate though. This only adds to the existing package-provided build-depends/conflicts; it doesn't affect where they come from. 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
