Subject: Re: Package Paths Proposal v2
To: Curt Sampson <cjs@cynic.net>
From: Todd Vierling <tv@pobox.com>
List: tech-pkg
Date: 12/16/1998 18:11:45
On Wed, 16 Dec 1998, Curt Sampson wrote:

: > What programs?  Ones that don't need starter files are moot; ones that do
: > simply need to have pkg_add create the /var files for them.  I must've
: > missed something here.
: 
: I'm thinking of a program where the /var files are generated as
: part of a `make install.' For example, if msgs were a package, it
: needs to start with a /var/msgs/bounds file that contains the line
: `1 0' in it. If we can't copy that over on the NFS client machines,
: we have to create it. If you think it's better to use an alternate
: form of @exec to create it, I suppose I can live with that.)
: 
: (We need to forms of @exec, one for stuff to be run once on the
: server, and one for stuff that needs to be run on every client.)

You're referring to the same `starter files' I was mentioning.  In the case
of msgs, the binary pkg PLIST would do an `@exec echo "1 0" >/var/msgs/bounds'.

In the case of programs that have more involved files, the pkg Makefile
would copy it from the `installed' location back to libdata, so that a
binary pkg could @exec cp it into the right place.

Whether or not this is a special @-command is more dependent on making it
work for client machines, which would probably need it.  I think it might be
nice to have a generic @client command that means `run as part of a
client-only install'.

: > A directory, of course.  That's not a _single_ file.  :)
: 
: Right. So you could have
: 
:     /usr/pkg/share/examples/someprog/conf1
:     /usr/pkg/share/examples/someprog/conf2
:     /usr/pkg/share/examples/someprog/conf1.example.1
:     /usr/pkg/share/examples/someprog/conf1.example.2
:     etc.
: 
: or
: 
:     /usr/pkg/share/examples/someprog/etc/conf1
:     /usr/pkg/share/examples/someprog/etc/conf2
:     /usr/pkg/share/examples/someprog/conf1.example.1
:     /usr/pkg/share/examples/someprog/conf1.example.2
:     etc.
: 
: I'd prefer the latter, since it makes it quite clear which are the
: default config files, and which are the examples for other
: configurations. It's more or less self-documenting.

That's fine, but why have the extra directory depth for, say, ssleay.cnf?
It looks fine right in share/examples (or, if you must,
share/examples/ssleay ;).

: However, I guess so long as pkg_add has an option to find the
: appropriate files in /usr/pkg/share/examples/someprog and copy them to
: etc, I can live with that too.

I was kind-of assuming this would exist.  I think we already went over
it....

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)