Subject: Re: Packages (Re: xntpd)
To: Jesus M. Gonzalez <email@example.com>
From: Hubert Feyrer <Hubert.Feyrer@rz.uni-regensburg.de>
Date: 01/04/1996 16:06:51
> 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
documentation is also available as
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
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
> >Also, some more thoughts on the "outer form" of the packages would be nice
> >have nailed down:
Maybe i should note that i came to many of those thoughts after reading the
docs from the Debian-Linux-distrib
> > - 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
> > 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
(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
> 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
=============== Hubert Feyrer ============================================
Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/943-2905
Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084
Internet: firstname.lastname@example.org, IRC: hubertf