[buildd-tools-devel] Bug#607228: Bug#607228: no way to run setup command inside a chroot

Roger Leigh rleigh at codelibre.net
Mon Jan 3 23:26:34 UTC 2011


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20110103/35a8ffbd/attachment.pgp>


More information about the Buildd-tools-devel mailing list