Hi Matthias, Matthias Klose wrote: > What do you mean by "before uploading into unstable"? I only included that phrase because I don't know whether the packages now in experimental represent Camm's final plans for them. For instance, if I remember correctly he was saying something about also shipping blas/lapack/atlas packages built with g77 even after the gfortran transition is finished. (I can't find the exact email though.) > If that is not > meant as a final package, then why not install the old and the new > libs in two different chroots? Certainly using chroots is an option, but it doesn't make things as easy on the users as having packages that can be installed in parallel does. > Non-conflicting packages would mean to upload with libraries with a > changed soname. I don't think that binaries are that portable, but > does it really make sense to keep both sets of libraries, and for each > package build for g77 *and* for gfortran? Regarding the soname: the Fedora maintainer of Cernlib has already changed the library sonames in his packaging, precisely in order to permit this parallel installability. (Note: upstream only builds static libs, so the distribution maintainers are free to choose their own sonames.) So to keep binary compatibility with Fedora, I think I ought to do the same unless there is a strong argument otherwise. The sonames have been changed in Fedora to (for a specific example) libpacklib.so.1_gfortran so I will rename the runtime library Debian packages like "libpacklib1-gfortran". (I'll keep the original libdevel package names.) My plan for Debian was not to build two sets of packages (one with g77 and one with gfortran), but only to build with gfortran, change the runtime library sonames and package names, and not explicitly conflict against the old g77-based packages. In that way users can keep the old g77-based runtime library packages from Etch on their system if they want. Of course this plan only works if the two versions of LAPACK/BLAS also will be possible to install in parallel, hence my question to Camm. If not, I'll still have to change the Cernlib library sonames to keep compatibility with the Fedora packages, but I wouldn't have to concern myself with taking care of parallel installability. > PS: Seems that we are still stalled, so currently I'd prefer anything > that brings us a bit forward... Understood, I will try uploading Cernlib packages to experimental in the near future that have the soname change but still conflict against the old runtime library packages. best regards, -- Kevin B. McCarty <kmccarty@gmail.com> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751
Attachment:
signature.asc
Description: OpenPGP digital signature