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:

    "compat-cernlib-34-g77-2006-6.fc7.src.rpm" .

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 

http://www.environnement.ens.fr/perso/dumas/fc-srpms/compat-cernlib-g77-2006-9.fc7.src.rpm
http://www.environnement.ens.fr/perso/dumas/fc-srpms/compat-cernlib-g77.spec

(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
"compat-gcc-34-g77-3.4.6-7". Thanks!
            ^^     ^^^^^

You mean you'd like the cernlib package to be named
compat-cernlib-2006-g77-2006-9 ???
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
compat-cernlib-2005-g77-2006-9
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:

http://www.environnement.ens.fr/perso/dumas/fc-srpms/compat-cernlib-g77-2006-11.fc7.src.rpm

In this version the soname of libpawlib-lesstif is rightly bumped, so
the compat-cernlib-g77-2006-9.fc7 package provides
libpawlib-lesstif.so.3  
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.

http://www.environnement.ens.fr/perso/dumas/fc-srpms/cernlib-g77-2006-15.fc8.src.rpm
http://www.environnement.ens.fr/perso/dumas/fc-srpms/cernlib-g77.spec

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"
-%bcond_with gfortran
-%else
 %bcond_without gfortran
+%else
+%bcond_with gfortran
 %endif
 
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 
compiled library.


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
/usr/lib/cernlib/2006-g77/bin/dzeX11 /usr/bin/dzeX11-g77
E: cernlib-g77-packlib only-non-binary-in-usr-lib
W: paw-g77 symlink-should-be-relative /usr/lib/cernlib/2006-g77/bin/pawX11
/usr/bin/pawX11-g77
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
to.

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.

APPROVED

Thanks for the review.

New Package CVS Request
=======================
Package Name: cernlib-g77
Short Description: General purpose CERN library and associated binaries
Owners: pertusus
Branches: F-7 EL-5

CVS done.