[csw-maintainers] Alternatives without automatic selection

[Philip Brown]

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'll note that debian has an explicit 'emacs-nox" (no X) package.


> 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.

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.

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.

 Randomness of behaviour on the user side,  is not a good policy.
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!"