Re: Experiment: poll on "switching to vim-tiny for standard vi?"
On Wed, Jan 04, 2006 at 07:29:10AM -0600, Steve Greenland wrote:
> On 04-Jan-06, 05:08 (CST), paddy <email@example.com> wrote:
> > Time to add a policy-alternatives hook to update-alternatives ??
> Huh? If the admin manually sets an alternative with with
> update-alternatives, it won't be overridden by a package install. What
> more does she need?
Maybe I have the wrong end of the stick.
I was thinking that if you wanted another possible behaviour:
say that optional packages don't overide important ones unless explicitly
set that way, then you could set that policy globally.
That way the policy could cover packages that haven't even been written yet.
Arguably an admin could fix things manually, but it isn't the same thing.
Or perhaps it's just something that noone would ever want ?
I don't have enough knowledge of the cases where alternatives is used,
to know whether anything would break, but given the nature of the mechanism
it seems plausible that it might just work.
Suppose I want to delegate the ability to install packages (lets say
from some limited secure source), but not have that activity mess
with the alternatives, or delegate control of alternatives.
Would that even work ?
Does it help make a policy-alternatives make sense ?
Even if the delegation example is nonsense is it hard to imagine that an
admin might simply have a multi-user system where this behaviour would
be the desirable rule rather than the exception ?
I appreciate the whole nice-for-the-single-user-by-default approach,
but it's nice to have the option to tell the packaging system to stay out of
the way as far as possible.
install x == replace y with less functional x
is not KISS, surely ?
I think you only have to look at this thread to get a hint that people
care about which text editor they use ;)
Perl 6 will give you the big knob. -- Larry Wall