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