[csw-users] Separating packages w/ non-/opt/csw files

[Nathan Coraor]

Hi,

I'm running in to some headaches while attempting to automate csw 
management in my environment.  Here's what's up:

/ Large-disk workstations
On my workstations with large enough disks, I install csw locally for 
added performance.  I have a script that updates these workstations 
using a package list (essentially, the output of 'pkg-get list' on a 
"master" server).  The workstation checks the master list to see what 
packages it's supposed to have and then runs 'pkg-get install' for 
packages it's missing, or 'pkgrm' for packages it has that are not on 
the list.  It runs 'pkg-get upgrade' regularly to automatically update 
software.

/ Small-disk workstations
On workstations with smaller disks, I NFS mount /opt/csw.

/ Issues
The problem comes from the non-/opt/csw files.  Some packages (such as 
enlightenment and enlightenment_dt) address this issue, but some don't. 
  For example:

My workstations are CUPS IPP clients that point at a central CUPS 
server.  To be a client, CUPS does not need to run cupsd, you simply set 
ServerName in client.conf and you're done.  This is fine for the NFS 
mounting workstations, but for the ones who install csw locally, I have 
to have my script go back and disable or remove the files that are 
placed in /etc/rc?.d to prevent cupsd from starting.

Conversely, workstations with a local csw will get the Xresources and 
Xsession for IceWM installed locally, so it can be started from dtgreet. 
  Workstations NFS mounting csw will not get that.

/ Solutions
What is essentially the solution for me is to have the script which 
updates software to do a few things:

* Check /var/sadm/install/contents for CSW packages containing 
non-/opt/csw files and index them.
* Maintain a list of CSW packages whose non-/opt/csw files need to be 
removed from large-disk workstations.
* Maintain a list of other, individual non-/opt/csw files that need to 
be removed from large-disk workstations (for cases when removing ALL of 
the non-/opt/csw files installed by a package is undesired).
* Maintain a list of CSW packages whose non-/opt/csw files need to be 
added to small-disk workstations.
* Maintain a list of other, individual non-/opt/csw files that need to 
be added to small-disk workstations (for cases when adding ALL of the 
non-/opt/csw files installed by a package is undesired).

One of the most difficult things about this is that should I need to use 
the 'individual files' lists (as opposed to the 'all non-/opt/csw files 
in X package lists), filename changes could make that list a pain to 
maintain.  For example, if the cups package maintainers decide to change 
/etc/rc3.d/S99cswcups to /etc/rc3.d/S98cswcups, I would have to change 
the list to reflect that.

Now, I realize that part of the problem comes from my multi-scenario 
environment... however, even if you were only using one of these two 
scenarios, you would have to address half of the issues.  I think a lot 
of this could be solved if all packagers took the same approach as the 
enlightenment maintainers: fork files that don't live under /opt/csw in 
to separate packages, and identify them as such.  Were this done, my 
script would simply need to have separate "master" 'pkg-get list' files 
- one for large-disk clients that excluded non-/opt/csw stuff I don't 
want, and one for small-disk clients that included non-/opt/csw stuff 
that I do want.  That's much less cumbersome to maintain.

It's excellent thath some package maintainers have already done this - I 
guess I'm asking that this package separation issue be made in to an 
actual Blastwave packaging guideline.  I may not be seeing the big 
picture, though, and doing so may cause more problems that I'm not 
thinking of... So please join in the discussion.

One somewhat related bit: Shouldn't stuff be delivered in an "off" 
(disabled) state, as mentioned in SMF guidelines?  It would then be at 
the discretion of the end user to decide whether or not to enable 
services.  This is generally considered a more secure practice, I had 
thought - one of the reasons the SST (JASS) disables everything.

Thanks,
--nate