1 |
I've been messing around with namespaces and some of what systemd has |
2 |
been doing with them, and I have an idea for a portage feature. |
3 |
|
4 |
But before doing a brain dump of ideas, how useful would it be to have |
5 |
a FEATURE for portage to do a limited-visibility build? That is, the |
6 |
build would be run in an environment where the root filesystem appears |
7 |
to contain everything in a DEPEND (including @system currently) and |
8 |
nothing else? It might be useful both in development/testing, and |
9 |
also in production use (not sure how performance would work in the |
10 |
real world - I was able in a script to get it to build an enviornment |
11 |
in a few seconds for a few packages). |
12 |
|
13 |
I really crazy idea would be to try to run packages in a similar |
14 |
environment, but I think that needs better kernel/etc level support |
15 |
since the performance hit would be much more noticeable, except for |
16 |
things like daemons that only start once. |
17 |
|
18 |
Implementing it wouldn't necessarily be hard - just create a tmpfs |
19 |
under /var/tmp/portage, unshare off a new mount namespace, and |
20 |
read-only bind-mount everything needed from the root filesystem |
21 |
(including /var/tmp/portage/...), and chroot into it. When the build |
22 |
is done the process governing it terminates and the kernel wipes out |
23 |
all the mounts and then portage unmounts the tmpfs. You wouldn't need |
24 |
to use a tmpfs for the build - it would actually be zero-size as |
25 |
reported by df since it just contains a bazillion bind mounts, though |
26 |
all those mounts would consume slab memory. |
27 |
|
28 |
Thoughts? |
29 |
|
30 |
Rich |