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

[Dagobert Michelsen]

Hi Ben,

Am 05.02.2010 um 19:52 schrieb Ben Walton:
> Excerpts from Dagobert Michelsen's message of Fri Feb 05 13:34:03  
> -0500 2010:
>> I guess the only way is to use an update-hook.
>> (/me taking deep look into http://wiki.opencsw.org/package-hooks)
>
> I agree with your assessment, but we should note that pkg-get doesn't
> support hooks yet (unless I missed an update), so this could be
> thorny.  Phil, are there plans to update pkg-get?  I know the last
> time this was mentioned, you didn't have the time.  Has that changed
> or is there someone else willing to add the feature?

Without hooks the manual selection would just not be preserved.

>> 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
>
> Would you even notice amidst the stock slowness of pkgadd/pkgrm? :)

Maybe I would, but with your appraoch below it won't be necessary :)

>> 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.
>
> Anyone know whether the Debian hook system has this limitation?  I
> hadn't envisioned this sort of package-specific hook when I came up
> with this.  The intent was for generic actions that should be done for
> all (or at least the bulk of) packages.  The system doesn't preclude
> this specificity, but I think it could be handled slightly
> differently.
>
> Deliver a single package containing the hooks required to handle the
> various cases presented by this challenge.  The hook looks for a file
> in /etc/opt/csw/pkg/CSWfoo/handle-altnernatives (or something) and
> takes the required action if that file is present.
>
> That way, you've made a CAS style generic hook script.  Would that
> work better than each package dropping it's own custom hook in the
> directories to handle (essentially) the same task?

Clever! However, and here comes the tricky part: Which package should
contain this generic alternatives-upgrade-hook? CSWalternatives itself?
I would think so, but is the user supposed to know of the differences
between pkg-get and pkgutil? Can we make him aware of differences in
upgrade procedures?

Anyay, thanks for the comment and for now I'll start adding the script
to CSWalternatives and do some more experiments.


Best regards

   -- Dago