Subject: Re: hier(7) silent on pkg documentation
To: William Allen Simpson <>
From: Volker A. Brandt <>
List: tech-pkg
Date: 11/07/2003 16:33:49
William Allen Simpson writes:

> /etc and /var have clearly distinct attributes and usages, and this
> would not work, especially on read-only mounted /usr.
> I'd prefer /var/pkg/<package>.
> Although /usr/pkg/etc seems to be the way things a few things are
> installed now, that's not defined in hier(7) the last time I looked,
> and /etc/pkg/<package> would be more rational.
> IMHO, /usr/pkg is like /usr/local.  Whatever happened to /usr/local?
> IMHO, /usr/pkg is kin to /opt, as defined by other systems, which also
> would lead toward /etc/pkg and /var/pkg....

I absolutely agree.  I have been using Solaris for a long time,
and the hierarchy is quite feasible.  The directories could be:

    Solaris		 NetBSD
    /opt		 /usr/pkg
    /etc/opt		 /etc/pkg	-- not /etc/usr/pkg
    /var/opt		 /var/pkg	-- not /var/usr/pkg

In practice, it gets complicated having a subdirectory under /opt
for every package.  In my experience, a hybrid approach works best.
Here's what we use under Solaris:

    /opt/<pkg>   -- for big standalone packages, such as StarOffice
    /opt/local	 -- for packages that fit in a "standard /usr/local"-
                 -- style directory hierarchy
    /usr/local -> /opt/local	    -- a symlink to make things easier

And here's what I use under NetBSD:

    /opt/<pkg>   -- for big standalone packages
    /opt/local	 -- for packages that fit in a "standard /usr/local"-
                 -- style directory hierarchy
    /usr/local -> /opt/local	    -- a symlink to make things easier
    /usr/pkg -> /opt/local	    -- another symlink

This of course means that there is an /opt/local/var which would
prohibit a read-only mount of /opt.  This could be symlinked out
to /var/opt/local, but I haven't found the ideal solution yet.

Actually, IMHO the confinement of packages under /usr/pkg and the
artifical separation of "add-on" packages (under /usr/pkg) and "system"
packages (nonexistent) is the single most glaring design flaw of
the NetBSD packaging system.  It makes implementing a fine-grained
hands-off installation for NetBSD that much more difficult.

I know that many of the shortcomings are just historic, and the
initial design goal was to make using the "ports" (FreeBSD-speak)
collection as easy as possible, but still...

Regards -- Volker
Volker A. Brandt                  Consulting and Support for Sun Solaris
Brandt & Brandt Computer GmbH              WWW:
Meckenheim, Germany                                   Email: