[csw-maintainers] Alternatives without automatic selection

[Peter FELECAN]

Philip Brown <phil at bolthole.com> writes:

> On 11/30/10, Geoff Davis <gadavis at opencsw.org> wrote:
>> ...
>> How does the alternatives mechanism handle package upgrades of an existing
>> package in the Linux world? If I recall, the RPM and Debian package managers
>> have the concept of "upgrade" rather than "Uninstall" followed by "Install".
>
> I think that is a side issue; if we just focus on pure "install", the
> central issue here becomes clearer. Please see below
>
>> I would assume therefore that the initial package installation order
>> determines in perpetuity what package is preferred. This would certainly be
>> the behavior that I would expect from the OpenCSW tools.
>
> well, it's exactly the opposite, from what you will get from a linux install.
> Try the following, with names adjusted as appropriate, in your linux
> distribution of choice that supports "alternatives":
>
> * install [vim-tiny]
>
> * use "vim". you'll be using "vim-tiny".
>
> * install [full-vim]
>
> * use "vim".
>
> Would you expect to still be using "vim-tiny", at that point, or full "vim"?
> either way, you'll GET full vim, unless you explicitly run
>
>   "alternatives --set vim vim-tiny"
>
> or whatever is the equivalent on that linux distro.
>
> Why would you expect any differently?
> If I, as a user, install a "better" implementation of something I was
> previously using, I would expect that any intelligent packaging system
> automatically use the "better" one, without me having to tell it to.
>
>
> For what it's worth.. seeing as how it's "OUR" tool, so we can
> customize how we like :), I could potentially see adding in some kind
> of configuration option in our tool, that behaves in a "first come
> first served" manner. However, given the common expectation out there
> of hundreds of thousands of linux systems working in the exact
> opposite way... there's no way that should be default behaviour.

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 (why give a higher priority to the graphical
version?) and everybody "magically" start to use the non graphical
version. I let you imagine how my dream team will react to that...

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