[csw-maintainers] User requests symlinking from /usr/bin to /opt/csw/bin

[Dagobert Michelsen]

Hi Phil,

Am 18.11.2009 um 18:09 schrieb Philip Brown:
> Hmm... there then becomes a question of, what to put in the package?
>
> for example, we have a gnu links package, that links ALL (or at least
> most) of the g-prefixed GNU utilities in /opt/csw/bin, to
> /opt/csw/gnu.
>
> That is a cross-package set of links.
> Should we do the same for this sort of request?
> If so, which packages/programs should we include symlinks for?
>
> or should we make a whole bunch of separate  CSWxxx"links" packages?
>
>
> OR... should we make a metapackage, with some sort of config file, and
> let the user decide?
>
> eg: CSWusrlinks, which will reference  one or both of
>
> /opt/csw/etc/cswusrlinks.conf
> /etc/opt/csw/cswusrlinks.conf
>
> and then if CSWxyz is mentioned there, it will make symlinks into /usr
> for that package.
> (in a postinstall script)
>
> ORRRRR... do we create another cswclassutils class, where either
> individual files can be set as in the "usrlinks" class, or it provides
> a config file, "if the user wants symlinks into usr for my package,
> make symlinks for the following files automatically..."
>
> I think this last one is perhaps the best long term option. for one
> reason, because it uses class action scripts instead of postinstall
> scripts, so it is the most future-proof.

I prefer the way Maciej has done it: with a separete package per
software (Cups in this case), marked incompatible to the Solaris
packages it replaces. You can't have that with classutils. And it
is cleanly separated from the CSW-only packages. If the "-ln"
suffix is consistent may be discussed, in the current naming
scheme "CSWcupslinks" would IMHO be better, but that is another
thing.


Best regards

   -- Dago