On 1/11/07, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
On Wed, 2007-01-10 at 09:40 +0100, Jakub Moc wrote:
> into pkg_setup and be done with it; no need for RESTRICT=sandbox or
> ACCEPT_RESTRICT. Users can decide whether they really wish to install
> such app and disable sandbox temporarily if they think it's a good idea.
Uhh... you missed RESTRICT=userpriv and the upcoming RESTRICT=unattended
when calling for no "ACCEPT_RESTRICT"...
> If you'd like to commit this to the official tree, then either fix it
> properly or don't commit such stuff at all.
That's very easy for someone to say when they're not the ones involved
in the work. Placing artificial limitations such as this really is a
bad idea. After all, we're all about empowering the user to make the
choice, so let them make the choice. If users want the package, why
should we stop them when it is technically feasible and not completely
asinine? Besides, if I want to maintain some nasty application that
doesn't work with sandbox, who are you (or anyone, for that matter) to
tell me that I cannot?
Hell, we could even *not* have sandbox/userpriv in the default
ACCEPT_RESTRICT, since they have possible security implications.
--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation
I know at least one person who have an automated/cron-jobbed upgrade
system, and I believe it would be useful as an extra application of
ACCEPT_RESTRICT for them to auto-accept upgrades which can be done
without breaking things without user interaction, and then
occasionally have them doing a manual emerge run with ACCEPT_RESTRICT
including the interactive requests to do the items which need their
presence.
My 2 cents.
Kent,
--
[email protected] mailing list
