On Fri, Jan 06, 2006 at 07:43:07AM -0600, Steve Greenland wrote: > On 05-Jan-06, 14:20 (CST), paddy <[EMAIL PROTECTED]> 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.
s/pointless/better/ ;) > 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 :( 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]