Bug#929433: lintian: warn on suspicious usage of dpkg-architecture variables

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#929433: lintian: warn on suspicious usage of dpkg-architecture variables

Graham Inggs-3
Source: lintian
Version: 2.14.0
Severity: wishlist

Hi Maintainer

I've noticed some packages have used incorrect dpkg-architecture
variables, e.g. DEB_BUILD_GNU_TYPE instead of DEB_HOST_MULTIARCH.
This may build successfully on the maintainer's amd64 machine, but could
FTBFS on i386 on the buildds.

It would be nice if Lintian could warn of possibly incorrect usage of
dpkg-architecture variables before the initial upload.

Regards
Graham

Reply | Threaded
Open this post in threaded view
|

Bug#929433: lintian: warn on suspicious usage of dpkg-architecture variables

Chris Lamb -2
tags 929433 + moreinfo
thanks

Hi Graham,

> I've noticed some packages have used incorrect dpkg-architecture
> variables, e.g. DEB_BUILD_GNU_TYPE instead of DEB_HOST_MULTIARCH.

So, DEB_HOST_GNU_TYPE is used quite a bit already:

  https://codesearch.debian.net/search?q=DEB_BUILD_GNU_TYPE+path%3Adebian%2Frules&perpkg=1

My two questions at this point are:

  a) Should all of these really be DEB_HOST_MULTIARCH?

  b) Are there any other "incorrect → correct" mappings?


Best wishes,

--
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      [hidden email] 🍥 chris-lamb.co.uk
       `-

Reply | Threaded
Open this post in threaded view
|

Bug#929433: lintian: warn on suspicious usage of dpkg-architecture variables

Helmut Grohne
Hi Chris and Graham,

On Thu, May 23, 2019 at 03:01:01PM +0100, Chris Lamb wrote:
> tags 929433 + moreinfo

I concur that this bug report is not actionable.

> So, DEB_HOST_GNU_TYPE is used quite a bit already:
>
>   https://codesearch.debian.net/search?q=DEB_BUILD_GNU_TYPE+path%3Adebian%2Frules&perpkg=1
>
> My two questions at this point are:
>
>   a) Should all of these really be DEB_HOST_MULTIARCH?

No! The majority of these are correct.

>   b) Are there any other "incorrect → correct" mappings?

Let me give you some patterns that are actually wrong:

https://codesearch.debian.net/search?q=--libdir%3D.*DEB_BUILD

These should all be using DEB_HOST_MULTIARCH.

https://sources.debian.org/src/go-dep/0.5.1-1/debian/rules/?hl=23#L23

Use DEB_HOST_GNU_TYPE.

https://sources.debian.org/src/libminc/2.4.03-2/debian/rules/?hl=7#L7

Use DEB_HOST_ARCH.

https://sources.debian.org/src/espresso/6.3-4/debian/rules/?hl=11#L11

Use DEB_HOST_ARCH_CPU.

https://sources.debian.org/src/gupnp/1.0.3-3/debian/rules/?hl=9#L9

Use DEB_HOST_ARCH_OS.


Using a quick codesearch, I was able to find maybe 10 occurrences. I
don't see any way to turn these examples into a common pattern. My
experience with filing cross issues is the this kind of issue is rare.
Around 1 in 100 cross bugs matches this kind of problem. We've mostly
sorted them out. I don't believe writing the lintian check is worth the
effort. We should just send patches for each of them and move on.

Graham, maybe you can send patches for each of these?

I'm in favour of wontfix.

Helmut

Reply | Threaded
Open this post in threaded view
|

Bug#929433: lintian: warn on suspicious usage of dpkg-architecture variables

Graham Inggs-3
Hi Chris, Helmut

Thanks for your comments.

I think this tag would be more useful for maintainers preparing new
packages, than for finding existing problems in the archive.  We can
just use codesearch.d.n for that.

On Thu, 23 May 2019 at 17:37, Helmut Grohne <[hidden email]> wrote:
> https://codesearch.debian.net/search?q=--libdir%3D.*DEB_BUILD
>
> These should all be using DEB_HOST_MULTIARCH.

How about emitting an info level tag when one of the less common
dpkg-architecture variables is used, and proving some hints regarding
the correct usage?

> Graham, maybe you can send patches for each of these?

I'll do that.

Regards
Graham

Reply | Threaded
Open this post in threaded view
|

Bug#929433: lintian: warn on suspicious usage of dpkg-architecture variables

Mattia Rizzolo-5
On Sat, May 25, 2019 at 09:56:15AM +0200, Graham Inggs wrote:
> How about emitting an info level tag when one of the less common
> dpkg-architecture variables is used, and proving some hints regarding
> the correct usage?

No, please don't.

tags of kind "this is unusual, are you really sure you want to do just
that?" are god only if the rate of false positives is really low.  This
is not the case.

--
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#929433: lintian: warn on suspicious usage of dpkg-architecture variables

Chris Lamb -2
In reply to this post by Graham Inggs-3
Hi Graham,

> I think this tag would be more useful for maintainers preparing new
> packages, than for finding existing problems in the archive.

They could still be false-positives for new packages, no? As in, I'm
not really seeing your distinction here between fresh vs. existing
packaging.

> How about emitting an info level tag when one of the less common
> dpkg-architecture variables is used, and proving some hints regarding
> the correct usage?

Mmm, but unless I'm missing something these could still have false-
positives too? Can you give some concrete examples for this so we
aren't talking too much in the abstract here?


Regards,

--
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      [hidden email] 🍥 chris-lamb.co.uk
       `-

Reply | Threaded
Open this post in threaded view
|

Bug#929433: lintian: warn on suspicious usage of dpkg-architecture variables

Graham Inggs-3
In reply to this post by Mattia Rizzolo-5
On Sat, 25 May 2019 at 10:48, Mattia Rizzolo <[hidden email]> wrote:
> tags of kind "this is unusual, are you really sure you want to do just
> that?" are god only if the rate of false positives is really low.  This
> is not the case.

Per one of Helmut's examples, all occurrences of --libdir=.*DEB_BUILD
were incorrect and should have used DEB_HOST_MULTIARCH instead.

Reply | Threaded
Open this post in threaded view
|

Bug#929433: lintian: warn on suspicious usage of dpkg-architecture variables

Graham Inggs-3
In reply to this post by Chris Lamb -2
On Sat, 25 May 2019 at 16:07, Chris Lamb <[hidden email]> wrote:
They could still be false-positives for new packages, no? As in, I'm
not really seeing your distinction here between fresh vs. existing
packaging.

Yes, there's definitely a risk of false positives.
But if a maintainer were about to upload a new package, or introduced changes to an existing package, that used DEB_BUILD* or DEB_TARGET* instead of DEB_HOST_MULTIARCH, I suspect the usage is most likely incorrect.

Mmm, but unless I'm missing something these could still have false-
positives too? Can you give some concrete examples for this so we
aren't talking too much in the abstract here?

Here are a couple I was able to find quickly:


Reply | Threaded
Open this post in threaded view
|

Bug#929433: lintian: warn on suspicious usage of dpkg-architecture variables

Helmut Grohne
Hi Graham,

On Sat, May 25, 2019 at 06:06:08PM +0200, Graham Inggs wrote:
> But if a maintainer were about to upload a new package, or introduced
> changes to an existing package, that used DEB_BUILD* or DEB_TARGET* instead
> of DEB_HOST_MULTIARCH, I suspect the usage is most likely incorrect.

Your suspicion may mislead you. A number of packages disable tests on
mips and mipsel, because its address space is so limited. This would be
a case where you would use DEB_BUILD_* as it is the address space of the
machine you are building on that is relevant here. For this reason
alone, I think "most likely incorrect" is incorrect.

> Here are a couple I was able to find quickly:
>
> https://salsa.debian.org/debichem-team/nwchem/commit/96a2bd29073d5f25c97fdf9ce0493857b31fcae0
> https://salsa.debian.org/r-pkg-team/r-bioc-rhdf5lib/commit/00bd8caa6689bf048d4f0f654993b0402a74cedb

Beyond confusing build and host, these confuse *_GNU_TYPE and
*_MULTIARCH. This used to be a relevant pattern indeed. We can turn it
into a codesearch query:

https://codesearch.debian.net/search?q=lib%2F%5C%24%5B%7B%28%5DDEB_%28BUILD%7CHOST%29_GNU_TYPE

The corresponding apt-file query does not yield any results however,
which suggests that we've fixed all of them.

apt-file search -x lib/i686-linux-gnu

I'm not sure what glibc and perl-cross-debian do in the codesearch
result, but the other occurrences look like they're either old changelog
entries or should use *_MULTIARCH. So using DEB_*_GNU_TYPE in a path
directly below lib is something that could reasonably be flagged with
few false positives. And it's also a mistake that can go unnoticed for a
while, because it only matters on i386.

And again the fingers of two hands almost suffice to enumerate all
packages matching this pattern. Again I question whether the effort of
turning this into a lintian check is well spent.

Graham, can I ask you to actually send those patches before continuing
this lintian discussion? I don't think this is moving us forward. Let it
rest a few days and gain more experience with the matter please.

Helmut

Reply | Threaded
Open this post in threaded view
|

Bug#929433: lintian: warn on suspicious usage of dpkg-architecture variables

Graham Inggs-3
Hi Helmut

Thanks again for your comments.

On Sat, 25 May 2019 at 23:07, Helmut Grohne <[hidden email]> wrote:
> And again the fingers of two hands almost suffice to enumerate all
> packages matching this pattern. Again I question whether the effort of
> turning this into a lintian check is well spent.

I am tending to agree.

> Graham, can I ask you to actually send those patches before continuing
> this lintian discussion? I don't think this is moving us forward. Let it
> rest a few days and gain more experience with the matter please.

It's probably only worth continuing if someone comes up with useful
filters, so let's leave it at that.

Regards
Graham