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

Yeah. That's what EazyInstall  is for ;)


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

Hu? Why fiddle with man.conf if you've links from the packages to
/usr/local/man? It's enough to just include /usr/local/man in MANPATH, works
fine not only under NetBSD. :)


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

I for myself, would also like to have a concept that includes other
architectures than just NetBSD, too. I don't have mixed platforms here, just a
bunch of Solaris boxes, but it'd be nice to have a general concept to handle
those as well (not to say that i wouldn't right now ;-).

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

Due to a better place, go for
ftp.uni-regensburg.de:/pub/NetBSD-Amiga/contrib/EasyInstall-1.3.tar.gz, the
documentation is also available as
ftp://ftp.uni-regensburg.de/pub/NetBSD-Amiga/docs/Packages.txt.

Please note that there's this is not Amiga-specific, i just didn't come up with
a better place. There's also a 1.3S, which works for Solaris.

Furthermore, i'm planning on 2.0, which will include some more programms, e.g.
for simplifying the creation of package-files.


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

Hm... true, but you'll have to mount more disks on /usr/local/test and prolly
/usr/local/distrib ;-)

The idea of /usr/local/install sounds ok, as it doesn't fill /usr/local up with
the packages but hides them in a single dir. :) I'd like to use another name,
though, as 'install' doesn't really reflect what's in there. How about
/usr/local/pkgs?


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

Maybe i should note that i came to many of those thoughts after reading the
docs from the Debian-Linux-distrib
(http://www.debian.org/Documentation/Debian/pckg.html#SEC1).


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

bin.bin sounds reasonable to me, too...


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

Yes... can't tell mu there as i didn't use pkg_tools before and i'm not really
familiar with it.


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

/mix?! :-> Now as there is /usr/share, i'd rather place it somewhere there...
shall we create a subdir under doc (doc/pkgs), or something like
/usr/share/pkgs? (in analogy to /usr/local/pkgs ;-)


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

I guess package-maintainance was mentioned by Rob Healey(sp?) or so, and i
agree that we would benefit from that concept. No more having to fiddle with
/etc/rc.local for adding some package.

If this concept should not be realized soon, we could help ourselves with
something like the following in /etc/rc.local:

for i in /usr/local/pkgs/*/install/bootscript
do
	$i start
done

(Assuming bootscripts are named 'botscript', live in a package's
'install'-subdir, pkgs live under /usr/local/pkgs and bootscripts use 'start'
and 'stop' as arguments - the latter just as with SVR4).

To make my statement: Using Solaris here on 15 machines, i like the
/etc/*.d-concept.

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

Sure... :) The list may not be 100% right, but why not move the discussion to
tech-install?


Hubert

-- 
=============== Hubert Feyrer ============================================
      Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/943-2905
      Weekends: Bachstr. 40,   D-84066 Mallersdorf, Tel. 08772/6084
      Internet: hubert.feyrer@rz.uni-regensburg.de, IRC: hubertf
==========================================================================