On Wed, 16 Dec 1998, Todd Vierling wrote:

> : Right. For those that are already familiar with it. If we grow more
> : or less exponentially, which I think is a reasonable assumption at
> : this point, a change now would, a year from now, affect only a
> : small proportion of NetBSD users anyway.
> 
> Before I say anything else, I'd like you to propose this as a _separate_
> proposal, so that others can see and talk about it.  I have a nagging
> feeling that it'll be shot out of the sky faster than a MiG in the wrong
> airspace.

It sounds like we're agreed that we should more or less poll the
rest of the developers and users and see if we get a large response
one way or the other. Let's leave this until we've settled other
things, then.

> : 1. Makefiles and build systems need to be updated to add
> : -I/usr/pkg/include -L/usr/pkg/lib when compiling programs that use
> : include files and libraries installed as packages.
> 
> Not much different form /usr/local.

Except that every Unix user knows about /usr/local; nobody but
NetBSD users know about /usr/pkg. Gnu autoconf also knows about
/usr/local, but not about /usr/pkg.

> : 2. /usr/pkg/bin must be added to the default path to have a `usable'
> : system in many people's eyes.
> 
> So we should probably add it to _PATH_DEFAULT and to
> `dot.{profile,cshrc,login}' afor the root uid and the skeletons.
> 
> And DOCUMENT it.

If we go this way, yes.

> This isn't, in my eyes, any compelling reason to mix third party software in
> with the stuff in /usr/bin.  Yes, we want to spread NetBSD around to more
> users, but we don't want to make the system a mess...

It's your opinion that that's a mess. I don't see why it is, since
with the PLISTs that we keep we can easily identify and remove
every package file that's installed. On many systems I find it
cleaner to mix than to separate, because that makes the whole system
more homogeneous, and I have to modifiy less configuration information.
(I've spent a lot of time over the last year making things look in
/usr/pkg/....)

> [etc.]

I agree to some extent with the arguments about the convenience of
separating pkg bins. We're not talking about just that; we're
talking about which is more convenient for users new to NetBSD.

> Frankly, I don't give a damn about new users to UN*X that won't even read
> the README file that tells them how to install the stuff.

Well, what can I say? This speaks for itself. I obviously want to
appeal to a broader class of users than you do. (I'd especially
love to start converting members of my local Linux users group;
this would help in that regard.) We'll just have to present the
arguments and leave this to others to decide.

> : > Grumble.  `var' should not be there - what example are you making for a
> : > volatile file?  :)
> : 
> : Empty scorefiles. Don't some programs need them present, and not
> : know how to create them?
> 
> If they do, then it should be created by a program, not by a human, and the
> starter files should go in libdata.  (Binary scorefiles in particular are
> typically host-byte-order dependent.)

Indeed, they should. But do all programs do this nicely, or not?
I'd rather leave the option open so that we can have somewhat
ill-behaved programs in our package tree. What compelling advantage
is there to not acommadating these programs?

> : Also for directory creation; if
> : /usr/pkg/share/examples/<pkgname>/var/games/somegame is a directory,
> : pkg_add should create a /var/games/somegame directory if it doesn't
> : exist. In fact, we may need to add an mtree to this to get permissions
> : right.
> 
> Yecch.  @exec install -d ... should be Just Fine, and this could be
> abstracted with a @-command to make it `usable across shares'.

Sure. I'd have a different command for it (@dir /var/foo/whatever)
so that the pkg_add command knows it's created as part of the `local
setup' when you do just that portion of the install.

> : > And without `var', why have `etc' in the path... just make it
> : > share/examples/pkgname/file.conf.  (And see edit-v2, also:  I mention not
> : > even having a pkgname subdir for uniquely named single config files.)
> : 
> : Because then we'd end up with the entire set of IPF examples being
> : copied over to /etc on install, for example.
> 
> Uniquely named SINGLE config files.

I thnk you missed my example here. Say we have a program that uses
two config files in /etc (conf1 and conf2), and provides three
examples of each beyond the default ones (conf1.example1,
conf1.example2, etc.). How do you set this up under share?

> That said, for this point I don't care much either way anymore.

Oh, now you tell me. :-)

cjs
--
Curt Sampson  <cjs@cynic.net>   604 801 5335   De gustibus, aut bene aut nihil.
The most widely ported operating system in the world: http://www.netbsd.org