>
>The structure you suggest (putting everything belonging to one package in a
>single dir) seems reasonably to me, too. Using pkg_tools won't be a problem
>this way, but you'll have to provide some methods so users don't have to
>maintain a list of directories for $PATH, $MANPATH, etc. for themselves.

	Now we are dealing with that using two methods:

	1. Links in /usr/local/bin, /usr/local/man, etc. That way,
when you upgrade to a new version of a package, just grep in that
directories looking for references to the old /usr/local/install/foo,
delete them, and make new symlinks. That can be easily automated.

	2. Scripts in /usr/local/bin, which invoque the binaries,
perhaps setting up some environment first. For man pages, modifications
to man.conf. This is more difficult to automate.

	We find interesting the ability of sharing code among different
archs (not only NetBSD in different archs, but also different OSs).
TeX and Emacs are a good example. We deal with that by using
/usr/local/install/share/emacs, for instance (wich using symlinks
can also be seen as /mix/share/install/emacs, which we find convenient).

>The
>EazyInstall-scripts could act as a starting point, but the package-file used
>there uses quite the same format as the pkg_tools need, so some work would be
>necessary there to reduce redundancy. If we settle on some common formats (see
>below), i can work on this.

	I've have having a look at RPM (used by Red Hut Software for
their Linux distribution). It is GPLd, and I'm not sure it's better than
pkg_tools (I'm still peeking on it). But has some interesting capabilites
(for instance, you can install directly via ftp). Info about RPM
can be found in http://www.redhat.com/rpm.html

	I know nothing about EazyInstall. Where can I get a copy?

>
>Furthermore, we should decide on some common directory and naming conventions
>for the packages' directories. I myself use /usr/local/<pkg>-<vers>, e.g.:
> ...

	We use /usr/local/install/for-2.3. That allows for some
other interesting directories:

/usr/local/test/foo-2.3: Where packages are built and tested.
/usr/local/distrib/foo-2.3: Where gzipped tared packages (original
  and patched distributions) are available. Useful for a ftp server.

	The 'traditional' /usr/local/bin, /usr/local/man, etc. are
mantained too (see above).

>
>Also, some more thoughts on the "outer form" of the packages would be nice to
>have nailed down:
> - ownersship of binaries

	Some packages need special permissions. This is well done 
with pkg_tools. For normal packages, I'd use bin.bin.

> - modes of files & directories

	pkg_tools deal also well with this when `special' modes
are needed.

	Anyway, I think that *the way*(TM) could be adding a `default'
command to pkg_create config file, so that you could say something
like:

@default file_mode 755
@default dir_mode 755
@default owner bin
@default group bin
@dir /usr/local/install/foo-2.3
@mode 1777 /usr/local/install/foo-2.3/tmp
@user nobody /usr/local/install/foo-2.3/tmp

	Of course, some tools to help in the writing of this file should
be needed. For instance, something that parses a tree and generates
a temptative config file, wich later on could be revisited by hand.

> - usage of symlinks

	See above.

> - how to deal with additional documentation? Include it into packages? Make
>   additional packages? Drop it alltogether? If not, where to put it? In the
>   package-dir? Somewhere else, like /usr/share/doc/<pkg>-<version>?

	Currently we are thinking about using /usr/local/install/foo-2.3/doc
or /mix/share/foo-2.3/doc for that, maybe with proper links
(like the one I mentioned for man pages) from /mix/share/doc.

> - Demands on pre-post-install/uninstall scripts: what arguments do they get,
>   how they are called, etc.
>

	This are probably the hardest part. And difficult to automate.
Some things (like editing config files) could be done with
patches. I found very interesting the idea of separate files for
the configuration of packages (and boot-shutdown scripts too)
wich was discussed some days ago. Maybe we should revisit it from
the point of view of the packages.

	Anyway, just to don't bother the rest of the people, if there is
interest we could discuss all of this in 'private' (all the
people interested), and offer back something detailed for everybody to
give their opinion. I can volunteer for sumarizing. Anybody interested?

		Jesus.

--
Jesus M. Gonzalez Barahona         | addr.:  c/ Butarque, 15
Grupo de Sistemas y Comunicaciones |         28911 Leganes, Spain
Departamento de Informatica        | tel: +34 1 624 94 58
Universidad Carlos III de Madrid   | fax: +34 1 624 94 30
e-mail: jgb@gsyc.inf.uc3m.es       | www: http://ordago.gsyc.inf.uc3m.es/~jgb