On Wed, Mar 12, 2008 at 08:38:35PM +0100, Joachim Reichel wrote: > Hi, > > >Currently build-deps read: > > > >Build-Depends: atlas3-base-dev [!arm !armeb !armel !m68k] | > >libatlas-3.so [!arm !armeb !armel !m68k], > >lapack3-dev [!arm !armeb !armel !m68k], ... > > > >You probably want just > > > >Build-Depends: liblapack-dev > > > >To transition to the gfortran compiled version of lapack/blas/atlas. > >It will automatically pull atlas on supported archictures, else it > >will use lapack.
> where can I find more information about the gfortran transition and about > its implication for package maintainers? http://wiki.debian.org/GfortranTransition > Is there no one-to-one translation > for the currently used package names? On what packages should cgal depend > if I want to keep an explicit dependency on atlas *and* lapack. If you want to remain explict: atlas3-base-dev -> libatlas-base-dev libatlas-3.so -> libatlas-3gf.so lapack3-dev -> liblapack-dev Now, compared to atlas3, atlas has not been able to build on all architectures: http://buildd.debian.org/~jeroen/status/package.php?suite=unstable&p=atlas So you would want to libatlas-base-dev [!alpha !arm !armel !hurd-i386 !m68k !powerpc] > My package has optional support for atlas *and* lapack. For maximum > flexibility of the library users I would like to enable support for both. > Thus I explicitly depend on both (e.g., linking with -llapack will not work > if just atlas is installed). My impression (but perhaps I'm maistaken, I did not follow the blas/lapack/atlas closely) is that atlas provides optimized versions of lapack and blas shared libraries. Now, since liblapack-dev has the following depends: Depends: libatlas-base-dev | libblas-dev | libblas-3gf.so, Which means, that you will get libatlas-base-dev (if available), else libblas-dev. Thats indirect rather than explict dependency, so depending what you want it is or might not be what you want. > Is there some information about the contracts/requirements for the involved > virtual packages? I contacted Camm Mcguire about this, but didn't receive > an answer. I'm not quite sure what you mean with this. -- "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]
