[csw-maintainers] Most shared directory entries
bwalton at opencsw.org
Thu Dec 29 14:49:48 CET 2011
Excerpts from Dagobert Michelsen's message of Wed Dec 28 16:45:08 -0500 2011:
> I have mixed feelings about directories in CSWcommon. Why do we have
> them at all? The only real reason I see for CSWcommon are the 64 ->
> (sparcv9|amd64) symlinks, and even those could be delivered in each
> package. Could you outline the real value of taking out directories?
Other than inertia, I don't see a huge benefit to this package. I
+1'd Maciej's post with the assumption that if we're delivering a
CSWcommon, it should be as sane as possible.
Aside from trimming the size of install/contents by some amount, I
don't really see much benefit to the package at all. I delivers a
single file (locale.alias) right now but if we drop the locale
directories entirely, then that would go too.
I think the only thing that I might deliver in this package if doing
it from scratch would be csw.conf that is referenced by quite a few
things (pkg-get, class action scripts, apache2 module installation,
etc). We could locally encapsulate the cswpreserveconf logic inside
the postinstall for CSWcommon to ensure that we don't overwrite
csw.conf with csw.conf.CSW. This would let us provide a fairly
current template of some sample options that can be set in the file.
I think many people don't realize that they have control over enabling
daemons, user id ranges, whether or not to enable apache modules,
etc. Much like pkgutil.conf.CSW, it would be at least useful to
showcase a set of capabilities with some documentation and other
> Additionally we should IMHO strip all locale subdirectories as this
> is a complete mess - we ship around 30% of the locale-specific
> subdirs and leave the others for inclusion in each package. If at
> all I suggest keeping only a minimum set.
Yes, that makes sense.
> One more thing: The cause for the warning after bootstrapping
> CSWpkgutil and then futher installing packages is because pkgutil
> does not have directory entries for the dirs in CSWcommon making
> them default owner:group, on update these are "don't belong to
> anything"-rewritten, so CSWpkgutil is probably a special case to
> disable exclusion completely.
That makes sense too, if we continue providing the skeleton directory
Replying to your other message, if we do carry this package forward, I
agree that having GAR be the authoritative source of the list is much
better than the current method.
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
More information about the maintainers