On 07/02/2012 01:36 PM, viv...@gmail.com wrote:
> Il 02/07/2012 22:01, Zac Medico ha scritto:
>> On 07/02/2012 12:48 PM, Pacho Ramos wrote:
>>> El lun, 28-05-2012 a las 14:34 -0700, Zac Medico escribió:
>>>> Hi,
>>>>
>>>> In case you aren't familiar with FEATURES=userpriv, here's the
>>>> description from the make.conf(5) man page:
>>>>
>>>>    Allow portage to drop root privileges and compile packages as
>>>>    portage:portage without a sandbox (unless usersandbox is also used).
>>>>
>>>> The rationale for having the separate "usersandbox" setting, to enable
>>>> use of sys-apps/sandbox, is that people who enable userpriv sometimes
>>>> prefer to have sandbox disabled in order to slightly improve
>>>> performance. However, I would recommend to enable usersandbox by
>>>> default, for the purpose of logging sandbox violations.
>>>>
>>>> Note that ebuilds can set RESTRICT="userpriv" if they require superuser
>>>> privileges during any of the src_* phases that userpriv affects.
>>>>
>>>> I've been using FEATURES="userpriv usersandbox" for years, and I don't
>>>> remember experiencing any problems because of it, so I think that it
>>>> would be reasonable to have it enabled by default. Objections?
>>> Looks like non important problems arised and, then, these could probably
>>> be enabled by default, no? :)
>> I'm not sure about the best way to handle migration for directories
>> inside $DISTDIR that are used by live ebuilds, since src_unpack will run
>> with different privileges when userpriv is enabled.
> tell the user to chown/remove the files/directories if and when needed,

How should we tell them? Elog message, news item, or both?

> unless there is a very good reason (try) to automate it.

I guess something like this might work in pkg_postinst of the portage
ebuild:

  find "$DISTDIR" -maxdepth 1 -type d -uid 0 | xargs chown -R
portage:portage

I would only trigger something like this once, when upgrading from a
version that doesn't have userpriv enabled by default.
-- 
Thanks,
Zac


Reply via email to