[csw-maintainers] Alternatives without automatic selection

[Geoff Davis]

On Nov 29, 2010, at 5:56 PM, Philip Brown wrote:

> On Mon, Nov 29, 2010 at 1:59 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
>> ...
>> Ok then, so you say identical prios are an error. That means
>> sendmail would get 100 and postfix 200 (or vice versay, doesn't
>> matter for the moment). User installs sendmail and configures it.
>> Than much later postfix is installed and everything breaks.
>> Does this sound better to you than my proposal?
> 
> Thank you for bringing up that example. We should definitely augment
> our documentation to cover it.
> 
> I have two comments.
> 
> #1: What you describe is, unfortunately, an example of another way to
> incorrectly implement 'alternatives' in a package. A package should
> not trigger 'alternatives', until what is referenced, is actually
> functional. We should document use of 'alternatives' to be clear about
> this.
> 
> 
> #2:  here's the biggest thing: .
> If you dont like the fact that the user will automatically get a
> different implementation inserted underneath things, when they install
> a higher priority implementation, I can understand that.
> But  ***this is exactly how they (LINUX alternatives) were designed to work***!
> 
> So if you dont like the way that feels as a user, then please make a
> formal proposal suggesting we stop trying to emulate "linux
> alternatives", and start using "Dagobert's Special Program
> Switcher(tm)" instead  :-D

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