[ On Thursday, November 6, 2003 at 20:56:33 (-0500), James K. Lowden wrote: ]
> Subject: Re: hier(7) silent on pkg documentation
>
> I agree with you, what's good for the goose is good for the gander. 
> Documentation of all kinds should be in /usr/pkg/share/, because it's
> machine-independent stuff.  

Exactly.

Use of $PREFIX/share is only half-baked in pkgsrc now, though it could
almost trivially be brought to 95% or greater completion by simply
moving the manual pages and texinfo documents into $PREFIX/share.

Of course with any even semi-modern hardware the need for, and benefit
of, keeping even "bulky" architecture-independent files together so they
can be shared between different types of systems via NFS or such is
almost nil, if not less (i.e. negative).  However if hier(7) says
sharable stuff should be in .../share then so be it!  ;-)

> > All non-manual page documentation should go uniformly into:
> > 
> > 	$PREFIX/share/doc/$PKGNAME
> 
> I was afraid a many-packaged system would become unwieldy without a
> hierarchy.  You don't think that's a problem?

No, I don't.

(but then I've never installed more than several hundred packages on any
given machine -- if several thousand are installed which each include a
share/doc file or directory then it may become unwieldy, but I think
that's the only thing that becomes unwieldy in such a situation and it's
probably the least of anyone's worries in such a situation  :-)

In any case I'm not sure using the package categories to rather
arbitrarily reduce the number of sub-directories per directory is of any
help.  It's difficult to discover which "category" a package belongs to
after it is installed ('pkg_info -B pkgname | fgrep PKGPATH=' does the
trick at the moment, but that's a very-less-than-obvious trick), and
separating those directories by aything other than something derived
directly from their name (e.g. the first character of their name) only
makes it harder to find them.

I like Alan's suggestion of including the location of any additional
documentation in the manual page(s) for a package (and creation of
minimal manual pages, perhaps even mechanically, for all those packages
which don't already have manual pages).  This leverages on the existing
indexing and search tools we have for documentation and it should be a
no-brainer -- i.e. let's just do it and get on with using the results!

It would also make sense to include in the default "pkg_info" output
some indication of what further documentation is available on the local
system for each package.  Sometimes this is done in a MESSAGE file, and
sometimes it's done in the DESCR file, but ideally it should be a
separate "field" in the database so that it can be uniformly queried.

> I can live with the "use xpkgwedge" approach, but I think it's arcane. 
> The point of pkgsrc is to make installing packages easy, contained, and
> predictable.  Writing to the system tree is contrary to that end.  

As others have said before, and we both say now, xpkgwedge should have
been the default for all of pkgsrc from the beginning.  Unfortunately it
wasn't.  It's not a "trivial" thing to make work automatically either,
especially since there are potential issues with upgrades and
re-installs of the base-OS X11 (or, imagine, an add-on X11 :-).

> Fundamentally, the whole X11R6 hierarchy is an interesting vestige of Unix
> history (the importation of X into Unix from MIT), but it has no technical
> merit at all.

Couldn't have said it better myself!  ;-)

>  It's really left over from the closed-source days, when
> vendors partitioned "their" code from MIT's.  Applications are
> applications, tools are tools.  X-ness is not a distinguishing attribute,

Well, I still remember the day when it mattered a great deal what kind
of device one had one's fingers and eyeballs glued to....
(and I still have a few DMD 5620 terminals out in the garage, and I've
sometimes had the crazy thought that it might be "cool" to get SunWindow
or NeWS working on NetBSD too, and I've friends with stacks of NeXT's,
and I probably shouldn't mention the likes of MGR, 8½, Aqua, etc....)

> any more than networkingness is.  

Well, I think network connectivity a whole different kind of ubiquity,
though I suppose if you take "IP" out of the picture then you can end up
in a whole other universe....

> > Personally I think hier(7) should be entirely silent on /usr/pkg, save
> > for this one sentence:
> > 
> > 	/usr/pkg	- mirrors the structure of /usr with the
> > 			  addition of /etc as /usr/pkg/etc.
> 
> Hear, hear!  /usr/pkg/var, while we're at it.

Well, I won't go that far -- which is why I explicitly didn't mention it.

Once upon a time I built systems with _all_ add-on stuff in /local, but
having to have separate /var and /local/var filesystems was painful and
then there was the issue of dealing with things that had to be shared
between system supplied tools and add-on tools, such as e-mail files.
Let /var be /var -- it contains machine specific, local, files, and
whether they are created/updated/used by base-OS utilities or add-on
utilities is irrelevant.

Personally I would vote for letting /etc be /etc as well, but too many
other folks seem to get all emotional about their configuration files
and it's just as easy for folks like me to make $PREFIX/etc be a symlink
to /etc.  (Configuration files are "configuration files", and they
should all be in one place, regardless of what they configure.)

(I could "ln -s /var $PREFIX/var" too, but that starts to get silly.)

Besides, "pkg_info -F" is (eventually) all you need to help you figure
out whether a file belongs to the base system or some add-on package, or
indeed what part of the base system it belongs to.  The location of a
file should be primarily determined by its function and purpose, not its
origin -- that's the main theme, and hopefully the goal, of hier(7).

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>