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. 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 [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
