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.
The original bug #243158, back in 2003 (!), was specifically about
/usr/lib's role as the place where shared libraries are stored, which
has mostly been replaced by /usr/lib/<triplet> these days anyway. For
example, the original bug report seems to have been about having a
pattern something like this:
/usr/lib/libbigloo.so.123 -> bigloo-1.2/libbigloo.so.123
I don't think the uses of /usr/lib in OpenArena, OpenJDK and LibreOffice
have anything to do with that pattern.
If there are concrete bugs that this tag is intended to detect, then I
suspect that would be better done by more narrowly-targeted tags.
Thanks,
smcv
