Re: Experiment: poll on "switching to vim-tiny for standard vi?"
On Fri, Jan 06, 2006 at 09:21:45AM -0600, Steve Greenland wrote:
> On 06-Jan-06, 08:28 (CST), paddy <paddy@panici.net> wrote:
> > On Fri, Jan 06, 2006 at 07:43:07AM -0600, Steve Greenland wrote:
> > > Then the whole update-alternatives priority system is made pointless.
> >
> > s/pointless/better/
>
> How? If you provide the ability to determine alternative selection based
> on package priority (Important/Standard/Optional/Extra), why do you need
> alternative priorities (numerical, set in in package maintainer scripts,
> locally overridable)?
currently, IIUC, there is auto and manual, where auto is
numerical, set in in package maintainer scripts
and manual is
locally overridable
My suggestion is that auto is the policy, of which there is currently one.
In a system with multiple possible policies, you would still need a
configured policy, but some example resultant possible combinations are:
based on package priority, locally overridable
numerical, set in in package maintainer scripts, locally overridable
in alphabetical order, locally overridable
ie: auto, manual == configured policy, manual.
Obviously, not all possible policies would be useful, but then noone would
write them.
> (The fact that we are using the word "priority" to mean two different
> things is perhaps confusing, which is why I've been trying to
> distinguish "package priority" and "alternative priority".)
Agreed, I am trying to disambiguate these priorities as I write, although,
without the same understanding of the existing system, I fear I may be
creating some confusion, for which I apologise.
> > > 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 ?
>
> We *already* have an override: it's called 'update-alternative'. Why do
> we need two?
the idea would be to make update-alternative extensible.
> > > 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"
>
> Sigh. No, it's "most of the time, for most people, our current system
> defaults in an appropriate manner, and for those rare occasions when it
> doesn't, we have the tool to override."
"If it ain't broke ?"
> > 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)
>
> It makes it harder for maintainers,
see below
> and it makes it harder for users,
debatable. more options is more complexity, sure. But many of the prior
arguments appealled to an admin who had control and knew what was going on.
Some of those arguments supposed an admin who wouldn't be well served by
the current (default and only) policy.
no need to change the default, just add a hook.
> because there would then be two completely different ways of overriding
> default alternative priorities.
I agree that this looks like a significant potential hazard, but ...
> Which would be dominant?
The existing system for making manual adjustments would be most dominant.
At the policy level, a given distro/release would need to have a default.
Since people would inevitably use different defaults in different distros
and releases and some admins would use non-default policies, interested
parties on a given system would need to inspect the configuration.
Having some portability in a way to do that might be nice.
> Which is preferred?
I don't understand.
"What's the default policy ?"
I see no reason for Debian to change it's existing default.
> How do you test all the interactions?
There may be an issue here, but I don't see it.
If the existing system is just one possible policy (albeit the default),
and any other policy relies on the same manual override but otherwise
any bugs are its own. Where are the interactions ?
> > 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 :(
>
> We have a straightforward system that provides a) reasonable default
> behaviour, and b) a standard way to override the default. I don't see
> the point in complicating that to provide a solution to a "problem"
> that has been invented just for this thread, and has *no* outstanding
> wishlist bug reports.
It's a random and probably flawed suggestion about how to accomodate both
viewpoints in a disagreement by a technical device. It's nowhere near my
todo list. I only hope I'm not wasting your time with a non-sensical
speculation.
Regards,
Paddy
--
Perl 6 will give you the big knob. -- Larry Wall
Reply to: