[csw-maintainers] Problem with "alternatives" on updates

[Dagobert Michelsen]

Hi Phil,

Am 05.02.2010 um 18:31 schrieb Philip Brown:
> On Fri, Feb 5, 2010 at 8:54 AM, Dagobert Michelsen <dam at opencsw.org>  
> wrote:
>> I guess we need
>> update-hook-scripts to handle this cleanly.
>
> I'm guessing we just need to think more carefully about how the PKG
> system works.
> Lets analyze things a little more deeply.

Yes. Before deploying :-)

>> I have tested alternatives on CSWautomake to switch
>> automake/aclocal between the included versions
>> 1.6 to 1.11. The problem is that if I manually select
>> a version (like 1.10) and then try to upgrade the
>> package the selection is not preserved. On
>> package deinstallation the choices are removed
>> from the alternatives system,
>
> Q1: do you mean "on deinstallation of CSWautomake"? I presume yes, but
> just want to make sure.

In the context of an update, yes. Which means pkgrm followed by pkgadd.

> Q2: Where is the information about the user choice stored?
> Is it solely in the symlink?
> If so, seems like the simple choice is to not have the symlink be part
> of the prototype file of CSWautomake, and then it wont go away.

The problem is slightly different: The symlinks are added dynamically
by "alternatives --install ... " on package installation (either
cas or postinstall) and removed by "alternatives --remove ..." on
package removal (either cas or preremove). The means the link is
not part of the package, but will go away on package removal.

There are two different cases:

1. Use alternatives to select different binaries inside a package
This would be used for CSWautomake, where there are multiple versions
of the same software inside the package. In this case the manual
selection should be preserved iff there is an update going on.

2. Use alternatives to select different flavors of an application
in different packaes.
This would be used for CSWmutt-ncurses and CSWmutt-slang. As you
either upgrade a package or simply deinstall it you cannot decide
from an in-package perspective if the current selection should
be kept or discarded.

I guess the only way is to use an update-hook.
(/me taking deep look into http://wiki.opencsw.org/package-hooks)

For case 1. the preupgrade- and postupgrade-hooks look useful to
copy the link from /etc/opt/csw/alternatives/... to the preservation
area similar to cswpreserveconf and replace the newly made link
in /etc/opt/csw/alternatives, but only iff the group is operating
in manual mode. The replacement should be done with --set to
readlink() (--set is btw. only available in the RedHat implementaion,
so we probaly choose the right one :-). Otherwise an addition of
a new version would not automatically lead to updated links even
if the group was in automatic mode.

For case 2. the situation is slightly different: When multiple
packages containing binaries of the same linkgroup are upgraded
and the same procedure as 1. would be used the link would be
preserved and recreated multiple times, but I guess it must be
this way as on --install in the cas of the package the link
would be adjusted and manual-mode will not be preserved on
complete deinstallation of the linkgroup.

One more thing about hook script naming conventions: When we
start putting *a lot* of hooks in the directories this can
become a serious performance bottleneck. I suggest to restrict
calling of scripts to scripts starting with [0-9]. Additionally,
scripts with the same name as the package are called. This way
we avoid executing possibly hundreds of scripts where each
one is only valid for a single package.


Best regards

   -- Dago