Camm Maguire writes: > Greetings! > > Matthias Klose <[EMAIL PROTECTED]> writes: > > > Camm Maguire writes: > > > Matthias Klose <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
