Bug#971707: lintian: breakout-link has lots of false positives, in particular for non-FHS trees below /usr/lib
On Mon, Oct 05, 2020 at 04:22:17PM +0100, Simon McVittie wrote:
> Package: lintian
> Version: 2.97.0
> Severity: normal
>
> The new breakout-link tag (warning about symlinks escaping from /usr/lib)
> seems to have a lot of false positives.
>
> In particular, the pattern I'm interested in for this bug report
> is that some upstream packages expect to be installed in a non-FHS
> layout where a single directory mixes executables with libraries,
> or mixes architecture-dependent executables and libraries with
> architecture-independent data, or mixes configuration with static
> files. This is very, very common in games, which are typically designed
> to installed in an arbitrary relocatable directory of the user's choice.
> It's also done in larger packages like OpenJDK and LibreOffice, in
> GNUstep apps (each of which is designed to be self-contained directory),
> and in many other packages.
>
> The long-standing convention for dealing with these packages in Debian has
> been to put their non-FHS tree in a subdirectory of /usr/lib. Files that
> would ordinarily be valid to appear in /usr/lib are shipped there as
> regular files, while files that would not be valid in /usr/lib are shipped
> as symlinks to a regular file in another location. For example:
>
> usr/lib/openarena-server/baseoa/etc/openarena-server -> etc/openarena-server
> usr/lib/openarena-server/baseoa/pak0.pk3 -> usr/share/games/openarena/baseoa/pak0.pk3
>
> Meanwhile, system integration (for example making the application appear
> in /usr/share/applications and in /usr/bin) is done either via wrapper
> scripts, or by moving or symlinking individual integration files.
>
> I don't think it's a good idea to encourage maintainers to patch these
> packages to use a FHS layout if their upstream would not accept that change.
> Unnecessary delta from upstream increases the number of bugs that exist
> only in Debian, leading to strained relations between upstreams and
> downstreams; and changing the layout has no real benefit for our users in
> cases like this, because we're installing the real files (such as
> /etc/openarena-server/server.cfg and .../baseoa/pak0.pk3) in the locations
> they should normally have.
>
> The tag description says:
>
> At least for /usr/lib, it is usually an error and may confuse
> some tools.
>
> [citation needed]? Which tools does it confuse, and which bugs does this
> check catch? I don't think setting the level to warning is justified
> unless a check genuinely prevents identifiable bugs.
I fully agree with Simon. The rationale for this warning
is lacking and there is no consensus in Debian this is a problem. Indeed
I would expect the consensus is that it is correct in a lot of common
situation.
Tools that are still confused by symlinks in 2020 need
to be fixed, not the other way around.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: