On Sun, 13 Dec 1998, Simon Burge wrote:

: > [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.

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

Right.  That's the `logistical problem' that I mention; saying that /pkg ->
/ or /usr gives you the ability to replace system binaries *assumes* that
the user will be making the symlink like that, and that leaves people that
do /pkg -> /usr/pkg stuck.

:  Also, without giving it too much thought, the "/pkg -> /" case gives me
: the heebie-jeebies.

Heh.  For me, '/pkg/usr' seemed awkward - and I have an addendum to this.

The symlink, I think, should exist at /usr/pkg, where we have the directory
now.  This means

- people that want to use /usr/pkg do *nothing* to change, leaving /usr/pkg
  as a directory,

- people that want to intermix just symlink /usr/pkg to /usr,

- existing binary pkgs Work as-is,

- bsd.pkg.mk doesn't even need to be changed,

- one fewer entry in /.

: 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?)

Actually, I've heard of a lot of people setting LOCALBASE to /usr/local.
That mechanism doesn't necessarily need to change; the proposal rather
assumed that the default would change to /pkg, and the addendum above
assumes no change at all.

: 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).

And bsd.pkg.mk, of course.

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

I'm personally agnostic here.  I don't use rc.d.

: 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")?

Yeah, pkg/libdata/pkgdb would probably be best, then.

: (do we then need a per-host database
: saying the the config/var files are installed?)...

`Yipe!'  :)

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)