Subject: Re: installing a pkg on multiple machines?
To: Julian Coleman <J.D.Coleman@newcastle.ac.uk>
From: Brian C. Grayson <email@example.com>
Date: 09/11/1998 12:07:34
On Fri, Sep 11, 1998 at 09:32:42AM +0100, Julian Coleman wrote:
> PS. Should there be a 'common problems' section to the package
> documentation? Something like :
[ Good suggestions deleted -- see current-users for them. ]
I'd also suggest adding a few notes on how to share /usr/pkg
over NFS, and how to set it up so that you can install package
A on machine X, and have machine Y notice that it's been
installed into the shared /usr/pkg. My ugly hack was to set up
two symlinks on all the machines:
/usr/pkg --symlink-> /usr/local (which was already NFS-shared),
and /var/db/pkg --symlink-> /usr/pkg/pkg.db,
but I'm sure there are more elegant ways to do this.
Another thing that has bit me, and might be worth a note, is:
pkg A through G use pkg H (aka Xaw3d :) version 1.3. Now you
want to install pkg I, which also depends on H, but in the
meantime H has been upgraded to 1.4, but there's not a major
difference between 1.3 and 1.4, so they can be used
interchangeably. In order to install I, you'll need to
install H 1.4, but first you need to deinstall H 1.3, but
that means deinstalling A through G and recompiling them all.
Add a few more dependencies (like gv on gs, and all sorts of
stuff on xpm), and you end up with a nasty dependence graph,
and have to pretty much deinstall and rebuild _everything_,
which is a pain for any of your users who are logged in
during that time trying to get work done with executables
mysteriously disappearing and reappearing. :) At least that
has been my experience with xpm and Xaw3d a few weeks/months
My quick hack has been, edit I's Makefile and change the
dependence to be on H 1.3. Nothing has broken -- yet. :)
There isn't currently any way to say ``any version from 1.3
through 1.5'' or ``version 1.3 or later'' is there? It'd be
handy in this situation.
The pkg stuff is very cool!
"With the current trend towards 'Object Oriented Programming,' programmers
must be continually aware of the inherent problems, primarily the 'OOPs'
factor. This is most pronounced in object oriented C, or OOPs-C." -- unknown