Re: dpkg-buildpackage now reorganizing debian/control Depends field??
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
Reply to: