[csw-maintainers] Alternatives without automatic selection

[Dagobert Michelsen]

Hi Phil,

Am 27.11.2010 um 00:38 schrieb Philip Brown:
> On Fri, Nov 26, 2010 at 1:06 AM, Peter FELECAN <pfelecan at opencsw.org> wrote:
>> 
>>> Would you consider same priorities a bug or a feature?
>> 
>> Definitely a feature! You example shows it clearly.
> 
> How is it a feature?
> what if the install order is effectively random? how is that a benefit
> to the user?

It may not be random if a user installs one MTA and configures it.
No MTA is better than another, if the prios were different another
MTA may supersede which is bad. The automatic selection of same
priorities should be persistent and saved similar to manual selection.

>> If we implement same priority alternatives and the order of installation
>> is rendered persistent
> 
> how can we possibly guarantee order of installation?
> That would seem to be up to the user.
> 
> This sort of thing will lead to the link given by 'alternatives' to
> start randomly changing, from a users perspective. This is a huge
> anti-feature!
> Any time a package is being upgraded:
> - it gets removed. alternatives gets called. 'oh, current alternative
> is no longer here. use next available for link'.

Right. Store "Previous automatic was 100 sendmail"

> - newer version gets added. alternatives gets called. ' oh. there's
> already an alternative in place of same priority. that one gets to
> keep the link'.

Nope. Sendmail gets added, current automatic selection is
"postfix 100", previous stored automatic was sendmail, restore
previous automatic setting if possible.

> the only way to implement any kind of "first installed, keeps
> priority", would be to effectively lock in "first installed", in
> basically the same way as a manual preference.
> IE; equivalent to    alternatives -set xxx yyyy

Similar.

> This sort of lock-in is supposed to be reserved to the user.
> To have the system do this pseudo-randomly based on "which got
> installed first", hidden in the background, is rather  against the
> whole principle of the 'alternatives' mechanisms.

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?


Best regards

  -- Dago