Re: Status of gfortran transition
Camm Maguire writes:
> 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.
how will you build the old packages once g77 is dropped from unstable?
> 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
I (and apparently others) don't like that and revert that change in
other packages. Could you make libblas3gf the default (first) choice?
For example libc6-686 isn't forced on users as well.
> 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. :-(
Reusing the source package name should work; blas3 would work as well.
> -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?
already answered; it's a warning, if you want to silence the warning,
then add on override file.
> In summary, is it useful at this juncture to take the version numbers
> out of the -dev packages with an eye toward the future?
It doesn't hurt.
Matthias
Reply to: