[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

On Fri, Jan 06, 2006 at 07:43:07AM -0600, Steve Greenland wrote:
> On 05-Jan-06, 14:20 (CST), paddy <paddy@panici.net> wrote: 
> > 
> > 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.
> Then the whole update-alternatives priority system is made pointless.



> Part of our job as maintainers and distributors is to make choices, so
> that *most* of our users don't have to. Then we generally provide a
> way to override those choices, for the remainder, who disagree with a
> particular choice or have a particular situation that is not covered by
> our choice.

and this would be just such an override, surely ?

> The choice we made many years ago for alternative priorities was based
> on these presumptions:
> A. Most people wouldn't care which of the alternative packages was
> installed so long as it provided the basic funtionality. 
> B. Of those who cared to install on of the variants, most would want to
> use the variant by default; after all, that's why they installed the
> variant.
> C. The 1% not covered by A and B can use update-alternatives to set
> their preferred version.

Understood, but it doesn't seem to answer my questions.

> Remember that people in class C are probably in class C *only* for one
> particular alternative, and are perfectly happy with the all the others.

okay so this is "noone ever wants to do that"

what about the delegated package installation example ?
Is that similarly flawed ?

I'm sorry to keep asking so many dumb questions, but would such a facility
make things any harder for maintainers ? (I have no trouble imagining that
it might, but I'm not familiar with the details)

> This is really a corner case, and while one should provide for corner
> cases, one probably shouldn't design around corner cases.

As I've tried very hard to indicate, I'm not clear on what the implications
would be, but I was kinda hoping that it might be a no-brainer, rather
than a design decision.  I'm still no clearer on that :(

Perl 6 will give you the big knob. -- Larry Wall

Reply to: