>>>>> On Tue, 8 Jul 2014, Michał Górny wrote:

> a) explicitly requesting user to alter group membership for the
> build user. This is already done in some of the CUDA ebuilds.

> [...]

This doesn't work out of the box for users, therefore it is not really
a solution.

> b) SUPPLEMENTARY_GROUPS support [2]. The idea is to use setgroups()
> to transparently enable group membership for the build process.

> Advantages:

> - transparent, relatively simple.

> Disadvantages:

> - quite ugly name ;),

Certainly this can be changed. :)

> - doesn't cover other uses of FEATURES=userpriv.

Which ones? Are there examples for such uses in the Portage tree?

> c) 'esudo' helper [3]. This is a more generic form of (2), with
> support for other potential privilege changes.

> [...]

> Disadvantages:

> - hard to implement -- especially if we want to make it capable of
>   running bash functions.

Any idea how to implement it? Does it imply adding app-admin/sudo to
the system set?

> What do you think? Do you have other ideas?

Looking at the bugs that you have filed, it looks like most ebuilds
using userpriv restriction could be fixed, without any additional
support added to the package manager.

How many ebuilds will be left, after doing these fixes? Is it really
worth the effort then?

Ulrich