Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Sergei Golovan]

Hi Felix,

On Thu, Jul 2, 2020 at 2:22 AM Felix Lechner  wrote:
>
> Hi Sergei,
>
> On Wed, Jul 1, 2020 at 1:33 AM Sergei Golovan  wrote:
> >
> > Though, the link never goes outside /usr/lib/x86_64-linux-gnu,
> > so I would say that this warning is spurious.
>
> I am not sure who is right, but the warning is not spurious from the
> perspective of the original requestor. Bug#243158 cited a scenario
> very much like yours as the reason for why the dynamic linker was
> confused.

As far as I can see, it's a link like /usr/lib/foo.so.1.0.0 ->
/usr/lib/somewhere/foo.so.1.0.0
was the concern for bug #243158. Here, Lintian emits a warning for the
link which
points backward (/usr/lib/ have the real file,
/usr/lib//lua have the link).

>
> Those links also never left /usr/lib.

The explanation for breakout-link says that there might be an issue
with multi-arch
(link may point to another architecture), so I'd just check and
wouldn'd show the warning
if both the link and the target are located inside one /usr/lib/.

>
> Like so many bugs in Debian, however, the feature was requested 17
> years ago. At that point, Lua had already been around for ten years
> (having arrived in 1993). Do you know when Lua adopted the current
> shared object hierarchy and resolution method?

I don't know when this layout was introduced in individual packages, I
can see that
it was implemented in dh-lua in 2012.

Cheers!
-- 
Sergei Golovan

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Felix Lechner]

Hi Russ,

On Wed, Jul 1, 2020 at 9:55 PM Russ Allbery  wrote:
>
> I'm not active and don't want to second-guess how
> you're handling things.

Thank you for writing that. I have likewise been reluctant to comment
on the good work of past maintainers.

> But I guess I'll say here that I think the point
> of a linter is externalized good taste.  It's a codification of good
> judgment calls about the way to construct a package.

I actually exercise relatively little judgment, at least by Debian
standards. On the contrary, I try to accommodate every bug filer, but
it is hard. People have so many expectations and styles. And often, my
solutions are not appreciated.

> I should have, and probably the answer is that I didn't read it in any
> detail.

It's never too late. I am happy to change the check, or to drop it
entirely, if you can figure out the original problem. It may involve
tools with which I am unfamiliar.

> That said, I think the way I would have interpreted that bug would have
> been to warn about symlinks inside /usr/lib to outside of /usr/lib.

That seems to be the consensus between Sergei, Chris and myself. It's
also what the check does now.

> looking at it now, I'm not sure what problem that would cause and
> therefore what purpose would be served by warning about it.

I am not sure, either. Perhaps a future bug report will tell.

> In general, I wouldn't assume that all the old bugs are valid or
> interesting.

After some reflection, I found that the most defensible way to close
feature requests is to implement them.

On a personal note, thanks for your book reviews. I serve as a library
commissioner in a town near you, and enjoyed reading them.

Kind regards
Felix Lechner

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Russ Allbery]

Felix Lechner  writes:
> On Wed, Jul 1, 2020 at 8:16 PM Russ Allbery  wrote:

>> I'm puzzled by why you would have changed Lintian in response to that
>> bug, given that the reported problem was only with Lintian and was
>> fixed sixteen years ago.

> I am just working through open bugs.

I didn't reply to an earlier discussion where you said something similar
because you're doing a ton of excellent work on Lintian and making a lot
of forward progress.  I'm not active and don't want to second-guess how
you're handling things.  But I guess I'll say here that I think the point
of a linter is externalized good taste.  It's a codification of good
judgment calls about the way to construct a package.  That means judgment
calls about whether a given suggestion is good taste or important always
felt to me like a significant part of the work.

> Why did you not voice your opposition as a maintainer during the past
> seventeen years, or close the bug?

I should have, and probably the answer is that I didn't read it in any
detail.  Lintian always had between 200 and 400 bugs when I was working on
it, and my work style was generally to pick a bug and work on it until I
could close it, rather than going through all of the bugs.  I also
prioritized newer bugs over older bugs.

That said, I think the way I would have interpreted that bug would have
been to warn about symlinks inside /usr/lib to outside of /usr/lib.  On
first glance, I might have thought that might be reasonable, although
looking at it now, I'm not sure what problem that would cause and
therefore what purpose would be served by warning about it.

In general, I wouldn't assume that all the old bugs are valid or
interesting.  I don't think I ever did a great job of triage, particularly
on older stuff.

-- 
Russ Allbery (r...@debian.org)  

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Felix Lechner]

Hi Russ,

On Wed, Jul 1, 2020 at 8:16 PM Russ Allbery  wrote:
>
> I'm puzzled by why you would have changed Lintian in response to that bug,
> given that the reported problem was only with Lintian and was fixed
> sixteen years ago.

I am just working through open bugs. Why did you not voice your
opposition as a maintainer during the past seventeen years, or close
the bug?

Kind regards
Felix Lechner

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Russ Allbery]

Felix Lechner  writes:
> On Wed, Jul 1, 2020 at 1:33 AM Sergei Golovan  wrote:

>> Though, the link never goes outside /usr/lib/x86_64-linux-gnu,
>> so I would say that this warning is spurious.

> I am not sure who is right, but the warning is not spurious from the
> perspective of the original requestor. Bug#243158 cited a scenario very
> much like yours as the reason for why the dynamic linker was confused.

> Those links also never left /usr/lib.

I'm puzzled by why you would have changed Lintian in response to that bug,
given that the reported problem was only with Lintian and was fixed
sixteen years ago.

What problem is this tag trying to address?

-- 
Russ Allbery (r...@debian.org)  

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Felix Lechner]

Hi Sergei,

On Wed, Jul 1, 2020 at 1:33 AM Sergei Golovan  wrote:
>
> Though, the link never goes outside /usr/lib/x86_64-linux-gnu,
> so I would say that this warning is spurious.

I am not sure who is right, but the warning is not spurious from the
perspective of the original requestor. Bug#243158 cited a scenario
very much like yours as the reason for why the dynamic linker was
confused.

Those links also never left /usr/lib.

Like so many bugs in Debian, however, the feature was requested 17
years ago. At that point, Lua had already been around for ten years
(having arrived in 1993). Do you know when Lua adopted the current
shared object hierarchy and resolution method?

Kind regards
Felix Lechner

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Chris Lamb]

Hi Sergei,

> Since it points to a higher location in the file system, lintian shows a
> warning. Though, the link never goes outside /usr/lib/x86_64-linux-gnu,
> so I would say that this warning is spurious.

Thanks for your report and it sounds like you are right. (Mostly
replying so you don't make changes to your package while you wait for
a fix to land.)


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#964073: lintian: Possible false positives for breakout-link for Lua modules

[Sergei Golovan]

Package: lintian
Version: 2.82.0
Severity: normal

Dear Maintainer,

Recently, lintian started to emit the breakout-link warning for a bunch of Lua
related packages. A typical structure of a Lua package with a C library is the
following:

The C library with a symlink (to allow someone to link a program in C to it):

/usr/lib/x86_64-linux-gnu/liblua5.1-sec.so.1.0.0
/usr/lib/x86_64-linux-gnu/liblua5.1-sec.so.1 -> liblua5.1-sec.so.1.0.0

The symlink which lets Lua find the library (by require "ssl")

/usr/lib/x86_64-linux-gnu/lua/5.1/ssl.so -> ../../liblua5.1-sec.so.1.0.0

Since it points to a higher location in the file system, lintian shows a
warning. Though, the link never goes outside /usr/lib/x86_64-linux-gnu,
so I would say that this warning is spurious.

Can it be fixed in Lintian?

I can think of another way of fixing it by reverting the linkage (make
/usr/lib/x86_64-linux-gnu/lua/5.3/ssl.so a real file and point the symlink
/usr/lib/x86_64-linux-gnu/liblua5.1-sec.so.1.0.0 to it), but I'm not sure
it's worth the effort.

Cheers!
-- 
Sergei Golovan