[ On Wednesday, March 19, 2003 at 00:27:38 (+0100), Jaka Jejcic wrote: ]
> Subject: Re: why separate system and pkg hierarchies? (was: /usr/pkg/etc/rc.d/*)
>
> 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.

I think your proposed security model is seriously flawed and your risk
analysis is way out of wack.  This is getting somewhat way off-topic,
but:  How do you ensure root never runs any program from any add-on
package?  Why don't you want your packages installed read-only too so
that they can be secure during production use as well?  Why do you worry
about the system being compromised if it crashes?  Why do you think
keeping packages out of the base system hierarchy will improve
reliability across crashes?

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

This is simply not possible within pkgsrc today, and likely never will
be possible.  Different variants of the same base software will almost
certainly always have unique package names, and also unique filenames
too when multiple packages can be installed simultaneously.

> it is very important, that pkg tools are not "the only" way to differenciate
> between system and add-on binaries.

Why?

> Otherwise we get rpms or stuff like that.

Huh?  What do you mean by "rpms or stuff like that"?  RPMs are just
another form of packaging system and they have the same basic benefits
as NetBSD's (FreeBSD-derived) pkg_* tools:  they help manage add-on
software packages so that the origins of every file can be tracked, and
so that add-on files don't clash between packages, and so that packages
can be independently de-installed and upgraded, and so on.

> Pkg tools should just provide a simple way of
> doing something one can do by hand as well.

The pkg_* tools do just do things that can be done by hand, but you
really wouldn't want to do without them....

(the same can be said about RPMs too I believe)

> So, how would you know (without the pkg tools) which is which if you only 
> have one dir?

Huh?  If you are installing packages then you are using the pkg tools
and they can tell you everything you need to know.

If you're not installing packages then obviously you're not talking
about "pkg hierarchies" so your point is moot.

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

How does that definition of trust have anything to do with what add-on
packages you use?

Or are you arguing that all the add-on software you use should
eventually be improved and integrated directly into NetBSD?

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

Sure, but that has nothing to do with where you put the add-on parts.
If you're installing packages then the package system manages the
identification and separation of those add-on parts and you don't need
to care where they are installed.

> This way you prevent things from becoming unexpected
> standards.

No, you don't.  Location alone does not identify a base component.
NetBSD already has different base "packages" (even though they are not
_yet_ properly recorded in /var/db/pkg).  Besides you'll always have a
manifest of which packages are installed on a given system (and within
each system you have a list of which files belong to which packages).
Any given production system has specific requirements which will include
those add-on packages -- i.e. they are by definition "standard" for that
system.

> Very similar thing happend with linux and is hurting us all.

Your paranoia about this is completley unfounded.

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

Indeed, but if you install add-on packages into the base system
hierarchy then anyone can add /bin/bash to their NetBSD system too (if
they're so inclined) and yet because they do it with the package system
they now know that /bin/bash is an add-on component and that when the
system it is installed on is upgraded or re-created then the "bash"
package has to be upgraded or re-installed too.

> I don't thing functionality is the classification key.

Oh, but it _IS_!  Consider it is the reason for the separation between
/sbin and bin, and it is also the reason for the separation between /bin
and /usr/bin (as well as for the separation between /sbin and
/usr/sbin).  It is also the primary reason for the separation between
/usr/bin and /usr/X11/bin.

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

But you can't wipe out the system (*).

You _can_ wipe out all packages with pkg_delete though, regardless of
where they are installed and without adversely affecting anything in the
base OS.

(*) well, I suppose you could if it were remotely mounted from some
other system, but that's stretching things a _lot_!

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

An extremely consistent OS would have all basic tools installed in the
root filesystem with at most only purely functional separation into
/sbin, /bin, /X11bin and so on (i.e. no /usr).  :-)

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