[ On Tuesday, March 18, 2003 at 21:52:40 (+0100), Jaka Jejcic wrote: ]
> Subject: Re: /usr/pkg/etc/rc.d/*
>
> But it is bad practice for sys-admins who want their
> sistem as clean as possible.

Why do you think it is bad practice to mix add-on packages into the
"system" hierarchies?  What justification do you have for making the
life of your users more difficult (as you seem to agree this will do)?

> We trust distribution and have no 
> particular reason to trust anything else.

Why don't you also "trust" the packages you install?  Why would you
install a package if you didn't "trust" it?  What, exactly, do you mean
by "trust" in this context anyway?

> If nothing more, stability and
> robustness of the system must never be questioned

How does installing a package in a system hierarchy question the
stability and robustness of the system?  I would consider my tightly
integrated systems more stable and robust than a system where components
are artificially separated based on classification scheme that is not
founded upon the component's functionality.

> Even more important is the fact that with growing complexity
> of one's system and the ambition to upgrade easily

How does installing a package in a system hierarchy make it more
difficult to upgrade your system?

Don't you just install the upgrade and then de-install and re-install
the upgraded versions of your packages?  That's certainly all I do.
You could even de-install the packages first, but I've never found any
reason to do that.

> the upgradeable part
> of the system must be clearly separated.

Why?  What do you think you gain by separating the base system from any
of its add-on parts?  Is that gain worth the added confusion for all
your users?

> That may be true and perhaps is stupit. But the fear that userland utilities
> won't be compatible or will have "too local" (#! tags) flavor is needless and
> two clean solutions exist.

I'm not talking about just any usrland utilities -- I'm talking about
scripts and programs that users may have in their own home directories
and thus things which each user must independently deal with as they
might move from system to system.  If "awk" is always in /bin/awk then
even when it's an add-on package on some systems then _every_ user
doesn't have to independenly worry about

> First is the autoconfig system which enables (and
> should obligate) programs to find their way out of "confusing" directory
> scheme.

Do you expect each user to autoconf all of their little tools?  That's
just not realistic.

> The other is to set a "user interface" unix style. We already
> have in unix tradition binaries separated from documents and that from
> libraries and so on. So why not have a directory of links to binaries for
> compatibility. The actual binaries can be save in their appropriate dirs,
> while users don't worry about them and use links.

While this has been suggested in the past, and certain other packaging
systems implement their "interfaces" using such a scheme, this is not
something we currently have with NetBSD's pkg_* tools so I don't see how
it's relevant.

I have only ever heard one single lone justifiable argument for keeping
add-on packages under a separate hierarchy and that's the situation
where they are installed on a fileserver to be shared amongst several
client hosts and where they are not also used on that same fileserver
_and_ where /usr is not also shared from that same fileserver.  However
as far as I can tell that is an extrememly rare situation, especially
these days.  If you're sharing /usr and /usr/pkg then why not just
install packages directly in the shared /usr and forget about managing
the second /usr/pkg share?  K.I.S.S.

(systems on which pkgsrc development are done do have justification for
keeping test packages in a separate hierarchy too of course, but those
systems are relatively rare special cases as well)

Now, just to be very clear about my position I'll note the separation of
X11 tools into their own hierarchy is justifiable, not because X11 is an
add-on package as a whole, but rather because it's a separation based on
the function of those tools.  It is a "Good Thing(TM)" to not clutter
the $PATH of non-X11 users with tools that they can never use in a
non-X11 environment.  In certain systems there's a separate hierarchy
for development tools (compilers and such), and that's arguably a good
thing too because of the separation by function.

Note also how confusing things get when you try to clash classification
schemes together.  We now have xpkgwedge which mixes add-on X11 tools
and other add-on tools into $PREFIX while in the base system X11 tools
are kept separate in their own hierarchy because of their functional
separation.  Why don't we have /usr/pkg/X11 too?

So in general I still see almost no reason to ever separate add-on
packages into their own hierarchy simply because they are not part of
the base system, especially not in systems intended for production use
as servers and what-not.

-- 
								Greg A. Woods

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