[csw-maintainers] Alternatives without automatic selection

[Peter FELECAN]

Philip Brown <phil at bolthole.com> writes:

> On Wed, Dec 1, 2010 at 2:08 AM, Peter FELECAN <pfelecan at opencsw.org> wrote:
>>  ...
>> I consider the MTA example a very good one. However, let's consider
>> another situation, a little bit similar with your use case described
>> above:
>>
>> I manage a server farm for a development team. Everybody uses
>> Emacs. Consequently, I installed the graphical version (GTK &c) for a
>> comfortable usage. However, there are some old fashioned people,
>> handicapped by their habits and/or equipment, who must use the non
>> graphical version. For those people the non graphical version was
>> installed. If alternatives were used, the order of installation will
>> determine the default one
>>...
>
> Situations where these "problems" come up when using alternatives, are
> situations where using alternatives, just isnt the best choice to
> being with.
>
> vim has the exact same "problem". which is why, as release manager, I
> bugged both the old maintainer, and then eventually the newer one, to
> maintain two separate packages, that can both be installed
> simultaneously, and allow people to choose which one they want, as
> their situation warrants.
> ("gvim" vs "vim")
>
> I dont have quite as much clarity of view into the emacs setup, so I'm
> sorry if I havent similarly bugged the emacs maintainer.
> oh wait.. YOU'RE the emacs maintainer. So, solve your own problem, why
> dont you? :-)

I solved this issue a lot of time before we had an alternatives package,
being the linuxsih one or the one that you hacked.

> i'll note that debian has an explicit 'emacs-nox" (no X) package.

We have it also and I decided to supply one when a user complained about
the X Windows dependencies.

>> Sometime there is no criteria on which to base a different priority and
>> the solution is to use the same one and depend on the order of
>> installation until someone make a reasoned decision and uses the
>> alternatives mechanism to change the defaults.
>
> Or.... dont use alternatives in the first place.

This is an original way to say: if the features of a current product
aren't complete and adequate do not use it. I don't think that in the
real world that you like so much this is an acceptable attitude. Or is
it?

> Or, just go with whatever the maintainer prefers as "top" priority,
> and presume the user/admin will use the --set option if they have a
> different opinion on order.

In the original post the case was exactly what the maintainer wants: to
set the same priority for a set of packages. What's different here?

> If the user is going to install only one of the possibilities, it
> doesnt matter if they have same priorities, or different priorities.
> If the user is going to install multiple of them... there's no reason
> to presume they will install their preferred one "first". It's quite
> likely they will install their site-preferred one SECOND.
> (they install package X. users complain, "hey, package Y is better".
> So they install Y, but other people still want X around)
> Or... they install both "at the same time". (pkg-get -i pkgA pkgB).
> It so happens that they one they care less about, gets installed first
> because of alphabetical sorting, so gets priority when they dont want
> it to. This is not serving the user well either.

This is very subjective but can be the case when and non knowledgeable
admin does things like you describe. However, after being confronted
with his disgruntled user base he will install in the good order.

>  Randomness of behaviour on the user side,  is not a good policy.

It's not policy but things happening in the real world.

> Order of install is often not an explicit priority-based choice, but
> effectively random. So having a sticky selection based on "first
> installed", is not a good policy.
> User would be better served knowing with certainty, "if I have both
> pkgA, and pkgB installed, then pkgB will ALWAYS get priority.. unless
> I override with --set"
> Rather than have to remember, "oh dont install pkgA, unless you've
> installed pkgB first!"

Well, in this case you lean toward deserving a part of the user
base.
-- 
Peter