I'll only include the relevant parts that I'm replying too.  Hopefully
Curt is keeping track of the whole thing ;)

I'll also say before I start picking at a few things that in general I'm
also in favour of this proposal.  I'm sure that not 100% of people are
going to agree with every single detail, and I'm sure that there'll be
some healthy discussion on these points too :-)


Todd Vierling wrote (in replay to Curt Sampson's original proposal):

> The biggest changes are, of course, that /pkg has no `usr' subdirectory (to
> reduce a *lot* of confusion possibility), /var is used directly, and
> /pkg/etc contains shared config files that can be replaced simply on a
> per-host basis, even with binary pkgs.
>
> [[ stuff deleted ]]
> 
> The user may set this symlink to /usr, causing the package stuff to be
> intermixed with the operating system files themselves.  This has some
> advantages, including that paths don't have to be changed; users just use
> their usual paths to find the installed packages. (cjs: In my personal
> experience, this would make it easier to convert Linux users.)

Another benefit here would be for when things migrate from the package
system to the base system.  bzip2 is a good example here - it more or
less appeared in the base system in -current and a package was added for
older systems.  If a user upgraded from 1.3.? to 1.4 with this system in
place, they are not going to be left with an old bzip2 binary hiding in
/usr/pkg somewhere.

> [tv: the other `advantages' have been pruned because there are some
> logistical problems with (b) and (c) that symlinking /pkg to / alone doesn't
> solve, particularly for those who *want* a near-pure separation of system
> and pkg.  Also, (d) is addressed by a changing of the handling of config
> files, below.  For completeness, (b)-(d) were:
> 
>     b) New package binaries (such as sendmail or named) replace
>     the current system binaries, thus avoiding the problems caused
>     when two different versions of a program are installed in
>     different places on the same system.  [tv: this has other logistical
>     problems, so symlinking to / doesn't quite cut it, but it helps.]

In the "/pkg -> /usr" case, you'd lose the ability of system packages
from replacing compontents in /bin and /sbin, right?  On the other
hand, I'd expect system packages to contain PLISTs that contain rooted
paths (like /bin/cat) that weren't relative to /pkg or wherever.  Also,
without giving it too much thought, the "/pkg -> /" case gives me the
heebie-jeebies.

> [[ stuff deleted ]]
> 
> 2. Files will be compiled to find their data, and installed, under /pkg in
> bin, sbin, lib, libexec, libdata, share, as per hier(8).  These would then
> equate to paths such as /usr/pkg/bin, /usr/pkg/sbin, etc., for the default
> case, and /usr/bin, /usr/sbin, /usr/lib, etc., for the intermix case.

So there will be a policy that "/pkg will exist in some form", whereas
currently you can set LOCALBASE to say /usr/local and there's no
knowledge of /usr/pkg at all on the system.  Seems like a small price to
pay in the scheme of things.  (How many people _don't_ use /usr/pkg as
the base?)

> 3. Configuration files: Programs use configuration files from /etc as the
> compiled-in default. Generally, subdirectories (/etc/<pkgname>) should be
> created for packages that have more than one or two config files. Sample
> configuration files should be placed in /pkg/share/examples/<pkgname>.
> The general algorithm for installation is:
> 
>     a) See if example config files exist. If they do, rename them
>     with a .old extension. (This facilitates a later diff(1) or
>     merge(1) to see and deal with configuration options that are
>     new or changed when a package is upgraded.)
> 
>     b) Install sample config files in usr/share/examples/<pkgname>.
> 
>     c) See if `real' configuration files exist in /pkg/etc. If not,
>     copy the sample config set over to /pkg/etc.
> 
>     d) See if `real' configuration files exist in /etc.  If not, add
>     symlinks for each from /etc to their corresponding files in /pkg/etc.

Having some PLIST magic to do this instead of duplicating the manual
sequence for each config file in each package would be really, really neat
(maybe something like "@etc etc/foo/foo.conf share/examples/foo/foo.conf"
or similar).

> [[ stuff deleted ]]
> 
> 6. Startup scripts: daemons that start at boot time should have a start/stop
> script available. This should be placed in /pkg/share/rc.d/<pkgname>. It

In the "intermix" case, you'd end up with rc.d files in /usr/share/rc.d.
I'm wondering if it should be a goal to then put standard system startup
scripts in /usr/share/rc.d as well (if we ever get to that) - I suspect
they'll all be MI, and if there are any that aren't we could still have
.../rc.d/${MACHINE} and/or .../rc.d/${MACHINE_ARCH}.  Aesthetically, I
prefer .../share/etc/rc.d but that won't kill me.

> [[ stuff deleted ]]

> 7. Package metadata: the files describing a package install (PLIST, etc.) go
> in /pkg/.pkgdb.  That way if a package is installed on a one system
> sharing /usr with others, it `appears' on the other systems (minus config
> files and var files).

Which maps to /usr/.pkgdb in the intermix case?  Having dot-files in
/usr sounds like a no-no.  How about /usr/libdata/pkg (hier(7) describes
/usr/libdata as "miscellaneous utility data files")?  Obviously /var/db
is the "right" place for databasey things, but then you lose the
sharability which is desirable (do we then need a per-host database
saying the the config/var files are installed?)...

Lex Wennmacher's idea of an "install-client" target sounds good here.
Bonus points for being able to do this from a read-only /pkg without
needing /usr/pkgsrc :-)

> [[ rest deleted ]]

Simon.