0004556: Major selection used by all packages does not work

(0008325)
phil (reporter)
2010-10-02 20:03

Okay. I've just made an updated version and dropped it in my experimental dir. please test.

Please also note, that it isnt exactly PRETTY :-/
but "alternatives --config mutt" actually works,and I've tested it myself as such.
So lemme know,and I'll push it out.

(0008326)
phil (reporter)
2010-10-02 20:04

PS: as a random bonus, i also added a flag unique to CSW: --list

(0008490)
dam (administrator)
2010-11-23 15:57

The priority does not need to be unique. I suggest using ckitem(1)

(0008495)
phil (reporter)
2010-11-24 19:26

What's the deal here... I put out a potential-fix package, but you give me no feedback as to whether it works for you?

I dont understand whether your last comment is related to the bug, or the new package, or general config of "alternatives", or...

My updated package has been sitting in experimental for a month.
Would you give me specific feedback on whether it fixes the problem in this bug report, please?

(0008496)
dam (administrator)
2010-11-24 22:55

It does work for some packages, but not for ones where all alternatives have the same priority. You should use ckitem on *each* alternative unrelated to the priority.
My last comment is about the package in experimental/.

(0008497)
phil (reporter)
2010-11-24 23:31

Thank you for the clarification.
Although there is still some ambiguity.

Do you mean "one file, with multiple alternative lines in it,
(not proper format in this example)

softA 10
softB 10
softC 10

or do you mean, "multiple packages implementing an 'alternative' for softA, and all packages give same priority for their alternative"?

I consider the second case, to be a bug in those packages.
If user installs "all packages", we need to have a reasonable path to install something as the "best" alternative implementation, without prompting the user.

PS: I also dont know what this "ckitem" is you are referring to.

(0008498)
dam (administrator)
2010-11-25 09:51

You are thinking too complicated here: "Alternatives" provides alternatives, where each alternative can have a priority. If the priorities are the same it is undefined which one is automatically chosen. For manual selection each alternative is listed together with the automatic priority and can be manually selected.

I can't believe you don't know /usr/bin/ckitem, this has been in Solaris forever and does just what you want here (see ckitem(1) for details).

(0008502)
phil (reporter)
2010-11-26 03:31

Okay, thanks for mentioning ckitem .But that doesnt affect the basic issue here:

As you have just noted yourself, having multiple alternatives with the same priority, for the same binary, disallows automatic selection.

This is a bug, not a feature.
If you want to bring this up on the main maintainers list for a discussion, fine.
But right now, I'm considering this a bug in the other packages, not CSWalternatives.

(0010544)
pfelecan (manager)
2013-08-25 15:33

Probably this has no more relevancy. If it's not the case, please re-open

Notes
(0008325) phil (reporter) 2010-10-02 20:03	Okay. I've just made an updated version and dropped it in my experimental dir. please test. Please also note, that it isnt exactly PRETTY :-/ but "alternatives --config mutt" actually works,and I've tested it myself as such. So lemme know,and I'll push it out.

(0008326) phil (reporter) 2010-10-02 20:04	PS: as a random bonus, i also added a flag unique to CSW: --list

(0008490) dam (administrator) 2010-11-23 15:57	The priority does not need to be unique. I suggest using ckitem(1)

(0008495) phil (reporter) 2010-11-24 19:26	What's the deal here... I put out a potential-fix package, but you give me no feedback as to whether it works for you? I dont understand whether your last comment is related to the bug, or the new package, or general config of "alternatives", or... My updated package has been sitting in experimental for a month. Would you give me specific feedback on whether it fixes the problem in this bug report, please?

(0008496) dam (administrator) 2010-11-24 22:55	It does work for some packages, but not for ones where all alternatives have the same priority. You should use ckitem on each alternative unrelated to the priority. My last comment is about the package in experimental/.

(0008497) phil (reporter) 2010-11-24 23:31	Thank you for the clarification. Although there is still some ambiguity. Do you mean "one file, with multiple alternative lines in it, (not proper format in this example) softA 10 softB 10 softC 10 or do you mean, "multiple packages implementing an 'alternative' for softA, and all packages give same priority for their alternative"? I consider the second case, to be a bug in those packages. If user installs "all packages", we need to have a reasonable path to install something as the "best" alternative implementation, without prompting the user. PS: I also dont know what this "ckitem" is you are referring to.

(0008498) dam (administrator) 2010-11-25 09:51	You are thinking too complicated here: "Alternatives" provides alternatives, where each alternative can have a priority. If the priorities are the same it is undefined which one is automatically chosen. For manual selection each alternative is listed together with the automatic priority and can be manually selected. I can't believe you don't know /usr/bin/ckitem, this has been in Solaris forever and does just what you want here (see ckitem(1) for details).

(0008502) phil (reporter) 2010-11-26 03:31	Okay, thanks for mentioning ckitem .But that doesnt affect the basic issue here: As you have just noted yourself, having multiple alternatives with the same priority, for the same binary, disallows automatic selection. This is a bug, not a feature. If you want to bring this up on the main maintainers list for a discussion, fine. But right now, I'm considering this a bug in the other packages, not CSWalternatives.

(0010544) pfelecan (manager) 2013-08-25 15:33	Probably this has no more relevancy. If it's not the case, please re-open

OpenCSW Bug Tracker