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
_______________________________________________
maintainers mailing list
[email protected]
https://lists.opencsw.org/mailman/listinfo/maintainers
