On 23/02/2008, Colin Tuckley wrote: > In the gFortran transition we have come across some cases where this > happens, depending on the order specified for depends you either get a > specialist (requested) package, or if you don't care which maths lib for > example is used by the package then you get a default one. Also it may be > that you get a software emulation of something rather than a faster hardware > version because you already have a certain library installed.
Well, let me take credit for first discovering this issue as the discussion ensues! :-) What the dpkg devels told me was that the package should build consistently on any environment where the Build-Dependencies were satisfied. However, this is, IMO, too much to ask. I describe it with this situation, which affected python-numpy, libitpp and octave. So, I want to build against the reference lapack and blas, and then, if the user chooses, then I want the alternatives system to enable the use of atlas. Now, the new dpkg-source reordering installs atlas as well during build, which causes the "smart" build systems of these packages to detedct and link against it, which is NOT what I want. OK, so I accepted the dpkg devels' advice, and either add a configure flag to the package build to make it oblivious to the existence of atlas, or, in the case of python-numpy, hack the build system in an ugly way to make it blind to the existence of atlas. However, this still has two disadvantages: 1. During the build, though atlas is never used, it is fetched and installed. This, may be termed insignificant, but I disagree. 2. Under the event that a user wants to rebuild my package _with_ atlas and link against it for some reason, earlier, he/she would just have had to install Atlas and run dpkg-buildpackage to achieve the desired result. Now, since my debian/rules has been made blind to atlas existence, the user would have to _undo_ my hacks/modifications manually to achieve the same result. And no, I cannot make the process too easy for users, because for the purpose of making the Debian package depend only on Atlas, I am forced to resort to this method, made necessary by the dpkg-source change. > > That said this new behaviour is not particulary new. It's been in unstable > > since the 19th november 2007. And we haven't seen major breakage in the > > mean time. > > There *are* breakages and more of them will come to light as the gFortran > transition proceeds. While what I describe isn't breakage, it is something which needs to be given some thought. > So, once again, please revert this change and then maybe we can all debate > what is actually needed (assuming any change at all is actually warranted). I stop short of saying +1, because I am not fully aware of the good reasons why dpkg developers resorted to this, but I am just very unhappy at being forced to work around what was an undocumented but "assumed normal" behaviour of dpkg suddenly changing. Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
