Red Hat Bugzilla – Bug 237579
Review Request: cernlib-g77 - General purpose CERN library and associated binaries
Last modified: 2007-11-30 17:12:02 EST
Spec URL: http://www.environnement.ens.fr/perso/dumas/fc-srpms/cernlib-g77.spec
SRPM URL: http://www.environnement.ens.fr/perso/dumas/fc-srpms/cernlib-g77-2006-6.fc7.src.rpm
This is a sort of compat package for the cernlib. Indeed in F7 the
cernlib is compiled by gfortran, however gfortran compiled libraries
are binary incompatible with g77 compiled libraries (and therefore
have a different soname). Moreover gfortran is sort of new, so I
think it is interesting to be able to use g77 and gfortran compiled
binaries and libraries in parallel.
The spec file is the cernlib specfile with the %bcond reversed in
order to have g77 used instead of gfortran. To have cernlib and cernlib-g77
packages available from the same spec file, there is a use of a lot
of conditionals, so the spec file isn't that legible, but in my opinion
it is more maintainable like that.
Jose, since you did the cernlib review, could it be possible for
you to review that one too? I'd like to have it in F7 if possible.
The package name should probably follow the notation already used for
other compatibility packages such as "compat-gcc-34-g77-3.4.6-7.i386.rpm".
One could thus imagine something something like:
The 34 is because the gcc version is 3.4 which is not the latest.
Here the cernlib version is the latest, so I think that no number
should appear in the name. As for adding compat in front of the
name, why not. I'll do a try.
Here it is. I also synced with the main cernlib
(In reply to comment #3)
> The 34 is because the gcc version is 3.4 which is not the latest.
> Here the cernlib version is the latest, so I think that no number
> should appear in the name. As for adding compat in front of the
> name, why not. I'll do a try.
The actual version of "gcc" which "compat-gcc-34-g77-3.4.6-7" is
referring to is "3.4.6". However, all compilers of the "3.4.x"
series are binary compatible. That's, I guess, why "34" is mentionned
in the first place. It does not refer to version "3.4.0". It simply
drops the minor version ["6"] which is irrelevant. If you omit "34"
in the package name, it is not clear against which version the
"cernlib" package has been compiled. E.g., it could have been built
against some "3.2.x" version which is not compatible with "3.4.x"
at the binary level! For this reason, I strongly support the inclusion
of "34" in the package name as had been done in the case of
You mean you'd like the cernlib package to be named
There is no specific binary incompatibility between the different
cernlib versions, and there may be binary incompatibility
within a version. Moreover the binary incompatibilities are in
the sonames. This is very unlike a compiler where the version
may be meaningful in term of binary incompatibility. Given
the nature of the cernlib since it is not actively developed
anymore, the binary incompatibility could certainly only come
from the packaging.
As a side note, in fact the current cernlib-g77 is binary incompatible
with the previous version -- not only because of the use of
gfortran -- but also because some code has been removed because
it was already in other libs. I haven't changed the soname
already because I was waiting for the debian move, seems that it
has happened. So it seems that you are somehow right that I will
need a compat package, and I'll certainly call it
but it will be in another submission...
(In reply to comment #6)
> You mean you'd like the cernlib package to be named
> compat-cernlib-2006-g77-2006-9 ???
No, I meant to name it "compat-cernlib-34-g77-2006-9" which refers to the
compiler release (3.4.x) against which it is built. Compatibility libraries
in "Fedora" usually carry labels like "296", "33" or "34" (as in this case) to
distinguish the underlying "gcc" version unambiguously.
It is not really built against gcc-3.4.x, the C compiler used is
the latest C compiler. It is only g77 which comes from gcc-3.4.x.
And (to my knowledge) g77 hasn't have binary incompatibilities for
a long time. So I can't see a reason to have a reference to the
g77 version, a reference to g77 seems enough to me.
Synced with the F7 version:
In this version the soname of libpawlib-lesstif is rightly bumped, so
the compat-cernlib-g77-2006-9.fc7 package provides
while there was libpawlib-lesstif.so.2 in FC-6. So I will submit a
compat package, named for example compat-cernlib-g77-pawlib-lesstif2
which will consist only of libpawlib-lesstif.so.2 and will be linked
against the compat-cernlib-g77 package. But first this package needs
to be accepted.
Since I plan to use the g77 compiled utilities, to solve (temporarily)
Bug 241416, I dropped the compat prefix. In any case it isn't really
needed in my opinion. Otherwise it is synced with devel.
This is an insanely big package with a mess of rpmlint complaints (mostly
unused-direct-shlib-dependency warnings), but if I understand correctly it
should be very close to the already-approved cernlib package. Is there any
chance you could simply list and explain the difference between this package and
the cernlib package? I'd be willing to ack it based on that if the differences
are small and reasonable.
The spec diff is only:
%if "%fedora" > "6"
This small diff somehow hides the real changes since the gfortran
conditional changes the compiler used, and also the packages names
and many file names/directory names to allow for parallel install.
So the differences are minimal but real differences have been done
in the main spec file by adding the conditional handling. This in
turn has been done first to allow to compile with gfortran or g77,
and later to have parallel installable packages.
The utilities linked against the cernlib compiled with gfortran
don't work (Bug 241416) After the package is accepted I plan to
use the utilities from this package as default (that is without
compiler string). The default library would still be the gfortran
The rpmlint warnings all seem not problematic to me, including the
unused-direct-shlib-dependency. They are the same that for the
gfortran compiled package.
After filtering out the unused-direct-shlib-dependency, remains:
E: cernlib-g77-devel only-non-binary-in-usr-lib
I don't really understand this one, maybe it is because
the .so symlinks are below a directory.
W: cernlib-g77-utils non-conffile-in-etc /etc/profile.d/cernlib-2006-g77.csh
W: cernlib-g77-utils non-conffile-in-etc /etc/profile.d/cernlib-2006-g77.sh
W: cernlib-g77-static no-documentation
W: patchy-g77 no-documentation
This is right.
W: cernlib-g77-packlib symlink-should-be-relative
E: cernlib-g77-packlib only-non-binary-in-usr-lib
W: paw-g77 symlink-should-be-relative /usr/lib/cernlib/2006-g77/bin/pawX11
E: paw-g77 only-non-binary-in-usr-lib
This is linked with the way dze and paw wrapper scripts work.
E: geant321-g77 devel-dependency cernlib-g77-devel
E: kuipc-g77 devel-dependency cernlib-g77-devel
E: cernlib-g77-utils devel-dependency cernlib-g77-devel
The cernlib-g77-utils and geant321-g77 packages contains
link scripts and env setting scripts, kuipc is for code
generation, they are distinct from devel to allow for
parallel installation of different cernlib version.
It was common practice before and I would certainly have
kept the previous version if the differences were big, but
now that cernlib is almost dead it is unlikely to be usefull,
but I still keep this possibility open. Also this way, even
though it isn't in maintained in fedora collection anymore,
users can take the cernlib-2005-devel package and install it
in parallel with the cernlib-2006-devel package if they want
Thanks for the explanation. I guess it would be preferrable for Jose Matos to
ack this since he did the original cernlib review, but he doesn't seem to be
around as much lately, so I'll go ahead and ack this.
Thanks for the review.
New Package CVS Request
Package Name: cernlib-g77
Short Description: General purpose CERN library and associated binaries
Branches: F-7 EL-5