Luke Mewburn writes:
> On Fri, Nov 07, 2003 at 04:33:49PM +0100, Volker A. Brandt wrote:
>   | Actually, IMHO the confinement of packages under /usr/pkg and the
>   | artifical separation of "add-on" packages (under /usr/pkg) and "system"
>   | packages (nonexistent) is the single most glaring design flaw of
>   | the NetBSD packaging system.  It makes implementing a fine-grained
>   | hands-off installation for NetBSD that much more difficult.
>
> I disagree.
>
> I like the fact that NetBSD's directory layout is:
> 	/		What NetBSD ships
> 	/usr/pkg	Third party pkgsrc packages
> 	/usr/local	_My_ locally installed stuff

Sure, that was the original motivation.  However, that motivation
did not cover everything.

> [...] I know people who've migrated
> from those systems who've remark that they prefer the
> separation that was chosen in NetBSD.

I don't mind separation.  In fact, I would advocate a separation
quite similar to yours listed above.

However, the point is:  We need a packaging system that covers
everything.  Separating out third party and local stuff should
be a function of the packaging system, not the entire scope.


Here's how it's traditionally done under Solaris:

  - The package database covers the world.  In fact, on an ideal
    system a cron job could erase everything that is not in the
    package database.  (Well, except /export/home and /tmp etc. :-)

  - Vendors should mark their packages using a naming convention
    (stock ticker symbol + trailing abbrev of pkg name)

  - Packages should be grouped using the CLASS variable.

(I am sure most of you knew this. Sorry for elaborating, but this
is important).


Stuff that Sun ships is prefixed by SUNW.  Freeware that Sun ships
is prefixed by SFW.  Packages we develop for customers are prefixed
by a customer prefix agreed upon with the customer.  Our packages
are prefixed by BBC.

The CLASS variable in the pkginfo file can hold several tags.
For example, a Sybase configuration package developed for BANK
could have CLASS=bank,sybase,bbc defined.  I could then catch it
with all the other customer packages using -c bank, group the
Sybase stuff using -c sybase, or find all the stuff we installed
at their site (including our tools) with -c bbc.

A user should not have to know about where an app came from or
where it currently resides.  There should be a limited number of
directories to add to the path (ideally, only one: /opt/local/bin),
and this should be done by the admin in some global shell rc file.

I have absolutely no problem with stuff from sunfreeware.com (which
I seldom use) and pkgsrc stuff and locally-built packages happily
sitting in /opt/local together.  As long as I can manage it using
my pkg* tools I'm fine.

I want system packages, and I want one package management tool
on my NetBSD machine.


Regards -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt                  Consulting and Support for Sun Solaris
Brandt & Brandt Computer GmbH              WWW: http://www.bb-c.de/~vab/
Meckenheim, Germany                                   Email: vab@bb-c.de