Subject: Re: Package paths: consensus?
To: NetBSD Packages Technical Discussion List <firstname.lastname@example.org>
From: Soren S. Jorvang <email@example.com>
Date: 01/14/1999 04:27:43
On Mon, Jan 11, 1999 at 12:46:59PM -0500, Greg A. Woods wrote:
> > I and probably others instantly think 'symlink tree madness' whenever
> > _symlinks by design_ comes up. This may be a bit of an .. emotional
> > argument, but I really do think they complicate the system in a
> > not-so-good way.
> That's why I keep emphasizing that the "B" option (and "C") allow for
> all other options with only two symlinks, whereas "A" would require a
> forest of symlinks in /etc (and possibly in /var) to maintain
(We don't want no steenking symlinks at all :-)
Ah, but while it would be nice if package configuration files were
segregated from the usual /etc/* bunch, they should not be physically
separate from the rest of /etc.
> > The point is that (host-specific) configuration and (less so) spool files
> > aren't ordinary files package-wise.
> Well, yes, and no. It depends on your requirements and perceptions.
> They are most definitely associated to some degree with their parent
> package. They do require storage private (or at least dedicated) to a
> particular host in *some* circumstances. Those circumstances are
> relatively rare, but they're extremely important since how they are
> handled will possibly make the decision as to whether or not a given
> system can feasibly be used in those circumstances.
We disagree here; I'd almost all configuration are, largely by
definition, host-specific. For exceptions (but I cannot really
think of any), /usr/pkg/etc (or whatever) would be fine.
> > The downside I see to A is that it clutters /etc and makes the operations
> > examplified by 'rm -rf /usr/pkg' (which I consider far from silly)
> > non-trivial.
> Indeed. Even if one uses the PLIST itself to mechanically decide which
> symlinks are necessary in /etc to move pkg files off to some other
> location, I still don't think it's a scalable option. An old VAX might
> never get out of namei() et al! ;-)
For me, the issue is how to make package-owned configuration in /etc
managable without it too complex.
I could certainly live with /etc/pkg/packagename/*, although that
may be a bit heavy for some people, although I think the people
so many voted A rather than C was because 'well, isn't /var/pkg/foopkg
and all that making a bit much out of it?'.
Again, alternatives such as /etc/pkg/allofthemtogether or /etc/pkg-*/*
are also within reason.
I think these naming details are what we need to clear up.
> > On the other hand, I don't consider a pure /var important enough to warrant
> > the /opt-like baroqeness of /var/pkg/foopkg/spool .
> Note that "B" (or "C") may result in /pkg/var or /var/pkg or a symlink
> of the same name. The package name does not necessarily enter into
> Whether or not /var is important to segregation depends on the
> application. /var files are almost always private to a given machine,
> but they may also be unique enough that some people will want to
> segregate them based on wether they are system files or pkg files.
/var is not so controversial, I think. I somewhat agree with
your idea of /var as throw-away. Anyway, the var files
of many packages really belong with other files in /var