Re: [Plplot-devel] PLplot statistics

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

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

> | 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?
>
> I don't quite understand your phrasing. libplplot only depends on the
> libs the xwin and tk drivers depend on, if they are build. Building
> dynamic drivers does not put dependencies in libplplot and in none of
> the executables, so I can build all dyn-drivers I can and package
> them.

It's that last phrase I disagree with (or perhaps misunderstand).  Here is
the current actual build results on my system (taken from make >&!
make.out).

gcc -shared -fPIC -o drivers/dg300.drv shared/dg300.o -L. -lplplotd

That's okay, it is consistent with what you have said.  But...

gcc -shared -fPIC -o drivers/gd.drv shared/gd.o  -lgd -lpng -ljpeg -lz -L. =
-lplplotd

So for this last line to work, libgd must be on the build system (our
configure system enforces this in any case). Furthermore, this (rightfully)
puts a dependency in the corresponding rpm package on libgd (and libpng and
libjpeg and libz and finally libplplotd).  So if you lumped all the *.drv
files in one binary rpm, that rpm would necessarily depend on libgd (and th=
e
other extra libraries).  If you split the *.drv results into one rpm per
*.drv file, then only the rpm containing the gd.drv file would have the
dependency on libgd (and other extra libraries), but you probably don't wan=
t
to generate quite so many different rpm packages.  So what goes on now for
my plplot binary rpm is virtually every dynamic driver is in there (as well
as libplplotd, etc.) and the whole rpm depends on libgd, libpng, libjpeg,
and libz (and also the many extra libraries required by gnome.drv which I
haven't mentioned until now).  IIRC, the only two drivers missing from my
plplot rpm are the svga one, and the cgm driver (since there is no viable
libcd rpm).  Anyhow, splitting off the dynamic drivers into their own rpm
package gains you little unless you micro-split them.  Only in that case
(drivers requiring special libraries in their own individual packages) do
you remove some dependencies of the main package on the special libraries.

I am sure Rafael is going through similar calculations.  In his case, thoug=
h,
I assume he will use the micro-split solution since apt-get makes life simp=
le
in that case.

> If "rpm" creates dependencies on the package, then one has to
> find the way to manually remove them (at rpm creation time).

I may be taking that remark out of context, but I think you will run
into trouble with such an approach.

> I know all that, I just wanted to stress the fact that one can
> distribute drivers even knowing that the user system might not have
> imediate support for some of them.

Only if you use the micro-split solution.
>
> I don't agree with Rafael idea of creating a separate rpm for each
> driver!

Actually, he made clear he was talking about deb's.  But I agree with you,
without apt-get a micro-split solution for rpm's is not too practical
so that is why I lumped everything together in the plplot rpm (with
the downside that it has a lot of dependencies that must be satisfied).


> What a mess to install all those perl modules! That's good only for
> debian, and for guys who know what they are doing. When I installed
> those perl modules I was tempted to (and just did)  install them all,
> because their names tell me nothing.

I believe you are referring to the perl modules required for building
the documentation?  I skipped all that for my rpm.  Too lazy....

Alan