Re: Status of gfortran transition
Greetings!
Matthias Klose <doko@cs.tu-berlin.de> writes:
> Camm Maguire writes:
> > Matthias Klose <doko@cs.tu-berlin.de> writes:
> >
> > > Changing the soname to a version which might be used by upstream for
> > > other purposes doesn't make sense. Please read our proposed transition
> > > plan (that resembles all other transitions which introduce changes not
> > > caused by the package itself):
> > >
> > > - do NOT change the soname
> > > - rename refblas3 to libblas3
> > > - libblas3 conflicts/replaces refblas3.
> > >
> > > This way you cannot have packages (archive or third party) installed
> > > together.
> >
> > OK, there is a problem here. The existing packages that depend on the
> > blas interface have the following runtime dependency:
> >
> > atlas3-base | refblas3 | libblas.so.3
> >
> > (defined in the shlibs.local) The latter is a virtual package.
> > lapack3, for example, acquires this dependency via linking in -lblas at
> > the last step. So installing libblas3 will replace refblas3, but make
> > anything linking against it or lapack3 segfault :-(. If the runtime
> > is made to conflict/replace, then we need to conflict/replace on
> > everything linked to it via some equivalent mechanism, I'd think, but
> > I'm sure I'm missing something here.
>
> correct, that's the reason that the refblas3 NMU now calls:
>
> dh_makeshlibs -a -V "atlas3gf-base | refblas3gf | libblas.so.3gf"
>
> and the lapack3 NMU:
>
> dh_makeshlibs -a -V "atlas3gf-base | lapack3gf | liblapack.so.3gf"
>
> > This just bit me, as I was building lapack, which requires a blas lib
> > dev, and it was using an atlas version, which was build against g77.
> > These are runtime incompatible, and that is what it appears sonames
> > are for.
>
> so the new refblas3gf/librefblas3 has to conflict/replace atlas3-base
> and liblapack.so.3 as well.
>
This appears really awful, given the proliferation of atlas optimized
libs on the 12 different arches, not to mention having one packge
conflcit/replace against another for which it is not the logical
successor.
BTW, why can't one conflict/replace on a virtual package?
> > I agree it might not be aesthetically pleasing to have an soname
> > differing from upstream, but I cannot see any other reason not to do
> > so. In fact, blas has no version number, so we make up an soname. It
> > would be ideal IMHO if the soname could be set to 3gf, but I'm not
> > getting too hopeful here (please tell me I'm overly pessimistic :-().
>
> there's nothing wrong to set the soname to this string. In this case
> you may not need to conflict/replace the old binary library package,
> if the packages don't conflict otherwise. Not sure, how much this will
> help.
I think this will help alot. In fact, this is what was done the last
go-round when migrating from soname 2 to 3. But that transition was
awkward in several respects, and I'd like not to make the same
mistakes this time.
To facilitate depending packages migrating on their own schedule, I
renamed the source at that time so that both soname 2 and 3 could
exist side by side. But then I had to uniquely name the -dev
packages, as no two independent source packages can apparently build
the same binary. But then this required modifications to all the
build-dep lines, which as you state is not that much of a problem now
as we have to do it anyway for g77. Still, I'd like to adopt a naming
scheme which would allow different runtime versions to coexist side by
side, while still providing an upgrade path that would not require
modifications to all the build-dep lines in the future.
It would appear the libdb1 -> libdb2 model is germane. Have an old
source package which just builds the old runtime, and the new source
package which builds the new runtime and all -dev packages, the latter
of which now no longer have version numbers in their names.
This is exactly like what you wrote above, but also taking the
opportunity at the moment to do some package renaming.
Would this suffice:
Source package: refblas3
Binary package: refblas3
SONAME/virtual provides : libblas.so.3
shlibdeps : atlas3-base | refblas3 | libblas.so.3
Source package: blas
Binary : libblas3gf
SONAME/virtual provides : libblas.so.3gf
shlibdeps : atlas3gf-base | libblas3gf | libblas.so.3gf
Binary : libblas-dev
Conflicts/Rep : refblas3-dev et. al.
Dev Alternative: libblas-3gf.so
Binary : libblas-doc
Binary : libblas-test
etc.
Issues:
source package blas still exists in oldstable (sarge) -- Can I reuse
this namespace yet? If not, I suppose blas3gf will do. :-(
-dev package conflict/replace -- especially since conflict/replace on
virtual packages does not seem to work, and perhaps for flexibility
reasons anyway, one might have atlas3-base-dev and libblas-dev
installed. If one links with -lblas, one gets whatever was in one's
search path (-L... or LIBRARY_PATH) (i.e. soname 3 or soname 3gf).
If one wants to know what one is getting, link with -lblas-3gf and
build-dep on libblas-dev (version) | libblas-3gf.so. This latter
will require an edit of the build-dep line whenever the soname might
need to change in the future. Using just libblas-dev and -lblas on
the otherhand will provide a permanent control signature to build
against the latest blas *if one uses a controlled package
installation environment like pbuilder, etc.* In other words, if
libblas-dev is the only blas-dev you have installed, or your search
path is the conventional one, you get the latest.
Finally, lintian appears to state that libfoo package names are
preferred. This means liblapack..., libatlas3gf-base,
libatlas-base-dev, etc. Yes or no? Should libblas-test by blas-test,
and with blas-doc?
In summary, is it useful at this juncture to take the version numbers
out of the -dev packages with an eye toward the future?
Take care,
>
> Matthias
>
>
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: