On Wed, Jan 04, 2006 at 07:29:10AM -0600, Steve Greenland wrote: > On 04-Jan-06, 05:08 (CST), paddy <[EMAIL PROTECTED]> 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 ;) Regards, Paddy -- Perl 6 will give you the big knob. -- Larry Wall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
