Bug#457151: Please reconsider closure of # 457151 -- it affects gfortran transition
Greetings! Just a quick note here -- I'd be most happy to tailor these to the needs of the community. I have an experimental gfortran atlas about ready for upload. Alas, I'll be away from the office for one week -- hope to get to it when I return. Take care, Kevin B. McCarty [EMAIL PROTECTED] writes: Riku Voipio wrote: On Sun, Jan 13, 2008 at 12:44:21PM -0800, Kevin B. McCarty wrote: 7) If dpkg was reverted not to re-order Build-Depends, I could force refblas3gf to be installed first, satisfying the dependency of lapack3gf on atlas3gf-base | refblas3gf | libblas.so.3gf and preventing the attempted installation of non-existent atlas3gf-base. I think lapack3gf depending directly on atlas3gf-base is the root of the problem. I would suggest moving atlas3gf-base dependency to recommends. Thus atlas3gf-base will be pulled onto enduser installations but not on buildd's (where recommends are not installed). I guess this dependency is caused by the shlibs file of refblas3gf being set to atlas3gf-base | refblas3gf | libblas.so.3gf. But if someone installs lapack3-dev, without specifically also requesting ATLAS, IMO it is most likely that they only want refblas3-dev and refblas3gf to be installed. (Otherwise the person would only have installed the ATLAS packages without worrying about the lapack3 packages.) Camm, do you think it would be possible to fine-tune the dependencies of lapack3-dev and lapack3gf so that they ask for refblas3-dev (respectively, refblas3gf) *before* atlas3-base-dev (respectively, atlas3gf-base) ? The former is trivial. Since I think the latter comes from the shlibs file of refblas3gf, I'm not sure how best to implement it. Maybe use an shlibs.local file in the lapack3 source package? So then lapack3-dev would have: Depends: refblas3-dev (= gfortran-transition-version) | atlas3-base-dev (= gfortran-transition-version) | libblas-3gf.so Obviously, substitute in the relevant version numbers for gfortran-transition-version. Also I'm not sure that I got the name of the virtual package right, but you get the idea. Note, the versioning of the dependencies should be added to the lapack3-dev package in any case, even if they aren't re-ordered; currently (at least on my machine) pbuilder is pulling in the version of atlas3-base-dev that hasn't transitioned yet, which is wrong! And lapack3gf would have: Depends: refblas3gf | atlas3gf-base | libblas.so.3gf If this can be done, please consider my objection to the closure of #457151 to be withdrawn. Camm, is it possible? best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- 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]
Bug#457151: Please reconsider closure of # 457151 -- it affects gfortran transition
On Sun, Jan 13, 2008 at 12:44:21PM -0800, Kevin B. McCarty wrote: 7) If dpkg was reverted not to re-order Build-Depends, I could force refblas3gf to be installed first, satisfying the dependency of lapack3gf on atlas3gf-base | refblas3gf | libblas.so.3gf and preventing the attempted installation of non-existent atlas3gf-base. I think lapack3gf depending directly on atlas3gf-base is the root of the problem. I would suggest moving atlas3gf-base dependency to recommends. Thus atlas3gf-base will be pulled onto enduser installations but not on buildd's (where recommends are not installed). -- rm -rf only sounds scary if you don't have backups -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457151: Please reconsider closure of # 457151 -- it affects gfortran transition
Riku Voipio wrote: On Sun, Jan 13, 2008 at 12:44:21PM -0800, Kevin B. McCarty wrote: 7) If dpkg was reverted not to re-order Build-Depends, I could force refblas3gf to be installed first, satisfying the dependency of lapack3gf on atlas3gf-base | refblas3gf | libblas.so.3gf and preventing the attempted installation of non-existent atlas3gf-base. I think lapack3gf depending directly on atlas3gf-base is the root of the problem. I would suggest moving atlas3gf-base dependency to recommends. Thus atlas3gf-base will be pulled onto enduser installations but not on buildd's (where recommends are not installed). I guess this dependency is caused by the shlibs file of refblas3gf being set to atlas3gf-base | refblas3gf | libblas.so.3gf. But if someone installs lapack3-dev, without specifically also requesting ATLAS, IMO it is most likely that they only want refblas3-dev and refblas3gf to be installed. (Otherwise the person would only have installed the ATLAS packages without worrying about the lapack3 packages.) Camm, do you think it would be possible to fine-tune the dependencies of lapack3-dev and lapack3gf so that they ask for refblas3-dev (respectively, refblas3gf) *before* atlas3-base-dev (respectively, atlas3gf-base) ? The former is trivial. Since I think the latter comes from the shlibs file of refblas3gf, I'm not sure how best to implement it. Maybe use an shlibs.local file in the lapack3 source package? So then lapack3-dev would have: Depends: refblas3-dev (= gfortran-transition-version) | atlas3-base-dev (= gfortran-transition-version) | libblas-3gf.so Obviously, substitute in the relevant version numbers for gfortran-transition-version. Also I'm not sure that I got the name of the virtual package right, but you get the idea. Note, the versioning of the dependencies should be added to the lapack3-dev package in any case, even if they aren't re-ordered; currently (at least on my machine) pbuilder is pulling in the version of atlas3-base-dev that hasn't transitioned yet, which is wrong! And lapack3gf would have: Depends: refblas3gf | atlas3gf-base | libblas.so.3gf If this can be done, please consider my objection to the closure of #457151 to be withdrawn. Camm, is it possible? best regards, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#457151: Please reconsider closure of # 457151 -- it affects gfortran transition
Dear dpkg maintainers,
Let me present to you a situation caused by the change to dpkg-dev to
install Build-Depends in alphabetical order:
1) atlas3-base-dev package provides an alternative version of
liblapack.so and libblas.so to the packages refblas3-dev and lapack3-dev
2) Maintainer of those packages (Camm Maguire, in CC) has the runtime
library package lapack3 Depend on atlas3-base | refblas3 | libblas.so.3
3) Up till now, it's been possible for a package (for instance, my
package Cernlib) that build-depends on these -dev packages to make sure
the runtime library package atlas3-base doesn't get installed, by use
of Build-Depends: refblas3-dev, lapack3-dev. The rationale at the
time was just that atlas3-base{,-dev} are larger, so take longer to
download and unpack, causing more wear and tear on buildds.
4) Now that dpkg re-orders Build-Depends, atlas3-base always ends up
installed since lapack3-dev comes alphabetically before refblas3-dev.
5) Until recently this was just an annoyance. But now that we are going
through the gfortran - g77 transition, lapack3 and refblas3 (runtime
libs) have been renamed to lapack3gf and refblas3gf. ATLAS has not yet
transitioned, so there is not yet an atlas3gf-base package existing.
But (in anticipation of it) lapack3gf already Depends on atlas3gf-base
| refblas3gf | libblas.so.3gf.
6) As a result, the version of Cernlib I just uploaded to experimental
for the purpose of furthering the gfortran transition FTBFSes on all
arches due to unsatisfied dependencies:
http://experimental.debian.net/build.php?pkg=cernlib
7) If dpkg was reverted not to re-order Build-Depends, I could force
refblas3gf to be installed first, satisfying the dependency of lapack3gf
on atlas3gf-base | refblas3gf | libblas.so.3gf and preventing the
attempted installation of non-existent atlas3gf-base.
8) If dpkg is not reverted, I fear that the progress of the gfortran
transition will come to a halt until ATLAS can be made to transition
(which due to technical difficulties could possibly be a long time in
coming).
So please reconsider the closing of this bug.
best regards,
--
Kevin B. McCarty [EMAIL PROTECTED]
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751
signature.asc
Description: OpenPGP digital signature
Bug#457151: Please reconsider closure of # 457151 -- it affects gfortran transition
Kevin B. McCarty wrote: 5) Until recently this was just an annoyance. But now that we are going through the gfortran - g77 transition, lapack3 and refblas3 (runtime Typing too fast; of course I meant g77 - gfortran transition sorry for the confusion, -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
