Re: [9fans] Man pages for add-ons

[Anthony Sorace <a@9srv.net>]

[-- Attachment #1: Type: text/plain, Size: 2018 bytes --]

	Unix has two camps for approaching this problem /usr/local and /opt.
While they're almost never followed well on modern unix systems, the
idea is basically a global local overlay vs. a per-package overlay.

	The /usr/local approach takes all packages not part of the base
system and creates a "local root", a global mirror of (roughly) the
root file system. Those poor souls don't have bind to work with, so
everything ends up "knowing" to look in /bin and /usr/local/bin, /etc
and /usr/local/etc, and so on. Packages from multiple sources are all
intermixed in one /usr/local, so you've basically got the base system
vs. everything else. EBo's /sys_aps is basically a recreation of /usr/
local.

	The /opt model creates per-package trees under /opt, for example /opt/
SomePackage. Within, it gets a similar looking overlay, but specific
to that package. It's then up to the user or site admin to determine
which packages get installed. Based on a similar (but much shorter)
conversation on inferno-list, a few of us are trying out this model
for third-party packages within Inferno.

	The Plan 9 approach today is either install everything in / (/386/
bin, /sys/include, &c) or in your personal home dir and bind as
needed. The later is irritating on multi-user systems, and the former
can make maintenance a lot harder. Replica's -c and -s help, but it
still requires more vigilance from the admin than it seems like it
ought to.

	Personally, I've always preferred the /opt model, as it makes it
easier to tell at a glance what's installed and to work with
components individually. The (non-)overlay can get unwieldy on Unix,
but our namespaces make that much easier for us. It also give both
admins and users package-level control over what gets included.

	Like I said, I and a few others have started playing with this in
Inferno. If it works reasonably there, I intend to try something
similar in Plan 9. Anyone likes to beat me to it, I'd love to hear
about your results.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 201 bytes --]