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

there are some examples:
1. let's say i want my system binaries to be mounted read only for
security reasones, and add-on packages read/write, so i can add remove
them as i wish. if the system crashes, basic system in not compromised.
2. let's say we have application with the same name... (system/pkg), then
it obviously shouldn't be installed in the same directory. This is not
as trivial as it seems. We mustn't limit add-on names by system utility
names. Things should be open both ways.

it is very important, that pkg tools are not "the only" way to differenciate
between system and add-on binaries. Otherwise we get rpms or stuff like that.
But that shouldn't happen. Pkg tools should just provide a simple way of
doing something one can do by hand as well. (if not, why not just use
a graphics application next, and forget about command line backend).
So, how would you know (without the pkg tools) which is which if you only 
have one dir? The importance of differentiation comes next ... in trust.

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

Trust means code that comes from the project. It is clean, writen in
accordance with NetBSD standards and complies with its phylosophy 
(including but not limited to: command line switches, manual pages, 
trojan-free, ...) I belive it is extremly important for the project
(long term sense) to keep to its standards. Keeping things separate
helps that a lot.
Each NetBSD system should have a standard part (system one) which is
more or less identical from box to box, and add-on part(s) which 
are specific. This way you prevent things from becoming unexpected
standards. Very similar thing happend with linux and is hurting us all.
Linux distributions started to include bash in /bin, Users quickly
assumed bash to be a definite standard and started writing shell scripts
with #!/bin/bash ... scripts which should be portable. Today, linux
can't be without /bin/bash because its users assume it is there.
I dont want NetBSD to adopt new programs in basic system just because
most users will use it. Again, it might be funny but that's how
systems become bloated. And bloated is what we must fear most.

To ease you a bit. It is not my intention to have irregular amount of
separation. It must (as it is) clearly defined finite number of separate
subsystems. 

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

I don't thing functionality is the classification key. It is the fact
that it can be (and often is) treated seperatly. For one thing mentioned,
it is installation. One can wipe out complete instalation and leave 
applications intact (quite similar to /home partition which is not mixed
with other dirs) it is applications vs system. So in a way it is even
separated on functionality.

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

However ridiculus this may seem, but it is not our goal to make as user
friendly os as possible. I belive we strive to make extremely consistent
os and make it user friendly as a consequence. Similary to making the
system clean and consequently secure.



jj