On Mon, May 12, 2014 at 12:46 PM, Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > On Mon, 12 May 2014 12:44:38 -0400 > Mike Gilbert <flop...@gentoo.org> wrote: >> On Mon, May 12, 2014 at 11:59 AM, Ciaran McCreesh >> <ciaran.mccre...@googlemail.com> wrote: >> > On Mon, 12 May 2014 17:46:57 +0200 >> > Alexander Berntsen <berna...@gentoo.org> wrote: >> >> On 12/05/14 17:23, Ciaran McCreesh wrote: >> >> > A flag being present or not in FEATURES does not mean anything, >> >> > and if you're assuming that it does then you have a bug. >> >> Please try to stay on topic, and don't obfuscate your posts >> >> needlessly. >> > >> > This is on-topic, and it tells you exactly what you need to know to >> > understand why your objection is irrelevant. But if you would like >> > it made simpler, but less precise: if you are looking at FEATURES >> > for anything that is not purely Portage internals, you are doing >> > something wrong. >> >> The idea would be to check for the necessary kernel features from >> portage backend code, not from ebuild code. > > Why, though? FEATURES doesn't give meaningful information to anything > other than Portage internals, so it doesn't matter. >
I'm not sure what you mean, but maybe we are just thinking about it differently. When FEATURES="network-sandbox", the kernel must have CONFIG_NET_NS enabled or the unshare(2) call will fail. We should probably emit an error message advising the user to enable the kernel option or disable the network-sandbox feature. This should happen when we call unshare() and that fails with errno == EINVAL.
