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
> segregation.

(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.

See below.

> > 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
> things.
> 
> 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
(/var/games/foo.scores).


-- 
Soren