Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Portage FEATURE suggestion - limited-visibility builds
Date: Thu, 26 Jul 2012 21:46:50
Message-Id: CAAr7Pr_SvzO11nxEpR5O4n2ppMAFimXeqhBw0vb36+DbObvYcQ@mail.gmail.com
In Reply to: [gentoo-dev] Portage FEATURE suggestion - limited-visibility builds by Rich Freeman
1 On Thu, Jul 26, 2012 at 8:26 PM, Rich Freeman <rich0@g.o> wrote:
2 > I've been messing around with namespaces and some of what systemd has
3 > been doing with them, and I have an idea for a portage feature.
4 >
5 > But before doing a brain dump of ideas, how useful would it be to have
6 > a FEATURE for portage to do a limited-visibility build? That is, the
7 > build would be run in an environment where the root filesystem appears
8 > to contain everything in a DEPEND (including @system currently) and
9 > nothing else? It might be useful both in development/testing, and
10 > also in production use (not sure how performance would work in the
11 > real world - I was able in a script to get it to build an enviornment
12 > in a few seconds for a few packages).
13
14 You mean like cowbuilder?
15
16 http://wiki.debian.org/cowbuilder
17
18 >
19 > I really crazy idea would be to try to run packages in a similar
20 > environment, but I think that needs better kernel/etc level support
21 > since the performance hit would be much more noticeable, except for
22 > things like daemons that only start once.
23 >
24 > Implementing it wouldn't necessarily be hard - just create a tmpfs
25 > under /var/tmp/portage, unshare off a new mount namespace, and
26 > read-only bind-mount everything needed from the root filesystem
27 > (including /var/tmp/portage/...), and chroot into it. When the build
28 > is done the process governing it terminates and the kernel wipes out
29 > all the mounts and then portage unmounts the tmpfs. You wouldn't need
30 > to use a tmpfs for the build - it would actually be zero-size as
31 > reported by df since it just contains a bazillion bind mounts, though
32 > all those mounts would consume slab memory.
33 >
34 > Thoughts?
35 >
36 > Rich
37 >