[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600036

Reply to: