List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On 03:01 Sun 06 Mar , Brian Harring wrote:
Thanks for your feedback, your remarks were correct :). I updated the
> I'd take a different approach here; this code basically assumes that
> the PM knows of it- note the chmod -s. The use flag protection you
> tried adding, without some profile hacks, is user modifiable- meaning
> users can flip it on even if the PM doesn't support it.
> Or consider that the code above is purely doing it's thing during the
> install phase, specifically against whatever filesystem is used for
> building- while capabilities might be able to be set there, it's
> possible the final merge location won't support it. End result of
> that is you'll get a setuid stripped binary merged to the
> livefs lacking the caps- borkage. Or consider the inverse- the
> buildroot can't do capabilities, but the livefs could. You get the
> Instead, write the code so the PM has to export a marker in some
> fashion to explicitly state "yes, I can do capabilities"- I'm
> specifically suggestining checking for a callback function exposed to
> the env.
> If that function isn't there, then the PM can't do it- end of story.
> If it is, the PM takes the args and will try to apply the
> capabilities at the correct time- stripping setuid/setgid if it
> Please go that route; and please do not stick "portage" into the
> function name, something generic we can use for a later EAPI is
> Implementing it as I suggested has the nice side affect of not being
> limited by PMS also, although it's an approach that still requires
> planning for compatibility.
I'm currently in search of a good fallback mechanism respectivly a good
mechanism to deal with cap-setting in src_install. As I already said in
my mail to ciaran, I'm going to give the new ideas some thought :).