Re: [Plplot-devel] PLplot statistics

[Alan W. I. <ir...@be...>]

On Fri, 8 Feb 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> On Thursday 07 February 2002 22:30, Alan W. Irwin wrote:
> [...] Those who use
> | a prefix of /usr for tarball installs or a /usr/local prefix for
> | rpm or deb installs get what they deserve....;-)
>
> Like me, when I made an automatic upgrade in my linux box, just to
> find that (of course) the upgrade had upgraded just the distro
> packages, not the manually installed rpm ones? And then searching for
> all them... it would be much easier if they were in /usr/local -- or
> if I had a separate rpm database just for them.

The way I used to organize this when I used rpm extensively was I would cop=
y
all the downloaded package files (e.g., plplot....rpm) to certain
directories. The contents of those directories would remind me what had to
be updated in the future.  Also, when actually building binary rpm's from
src rpm's the resulting binary rpm's are naturally placed in the RPMS/i?86
directory and the src rpm into SRPMS.

Under Debian I also do something similar to keep track of what has been
downloaded or built outside the official distribution.

>
> But I don't see the point in installing rpms under /usr -- there must
> exist some reasoning behind that?

It's traditional. Maybe its even in the LSB by now, but violate that
tradition at your peril.

>
> I have yet another rpm question. With dyndrivers, we can make rpm
> with all available drivers, without having to worry if the user
> system has the necessary libs or not! Of course the user will not be
> able to use those drivers, but it will not hurt, and if the user
> latter install the extra packages the drivers will be there. Correct?

Didn't we just go through this exercise to prove the libraries had to be
there (i.e., mentioned specifically for the link command) for the dynamic
driver builds?

Anyhow, when building from a src rpm we use the ordinary configure script
just like when building from a tarball or cvs. (And I am sure Rafael would
answer the same for the deb package build.) Our current configuration check=
s
for certain libraries and headers on the build machine.  If libcd is not
there it doesn't build the cgm driver.  If libgd isn't there, it doesn't
build the gd driver with png and jpeg devices.  This is uniform across src
rpm, (presumably) src deb, tarball, and cvs builds. Once the binary rpm's
and binary debs are available, and assuming, for example, that libgd was
found and linked with on the build machine, the packages will automatically
have dependencies on libgd, etc.  This forces the *binary* rpm user to
install the libgd package before the plplot package is installed (or in
Debian's case forcing apt-get to automatically install libgd before plplot.=
)
This is yet another reason why the tarball approach and the package approac=
h
(be it rpm or deb) should not be mixed for installation.  Time and again I
have heard users complain they cannot build packages on their Linux machine=
s
and often it is due to a dependency problem caused by using this mixed
approach.  If you understand enough to build a package from tarball it is n=
o
great leap to doing it from a src rpm.  I have done this many times (even
once with the whole tcl/tk src rpm package from RH 6.2, that I required on
my RH 5.2 machine at that time so I could play pysol (!)), and rarely run
into any insoluble problems. It is so straightforward, I would encourage yo=
u
to use src rpm builds rather than tarball builds just so you won't mess up
the package dependencies of your rpm-based Linux machine.

If you run into any specific problems with a src rpm build of say PLplot,
don't hesitate to ask me for help.  But my help will only be effective
if the system has been cleanly installed strictly from rpm's without
any forcing.

Alan