Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

1 view
Skip to first unread message

Aurelien Jarno

unread,
Aug 16, 2020, 6:10:02 PM8/16/20
to
Package: lintian
Version: 2.90.0
Severity: normal
X-Debbugs-Cc: debian...@lists.debian.org

Hi,

Since recent version of lintian, the following tags are reported against
the libc6-dev package:

W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libBrokenLocale.so -> lib/x86_64-linux-gnu/libBrokenLocale.so.1
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libanl.so -> lib/x86_64-linux-gnu/libanl.so.1
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libdl.so -> lib/x86_64-linux-gnu/libdl.so.2
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libmvec.so -> lib/x86_64-linux-gnu/libmvec.so.1
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libnsl.so -> lib/x86_64-linux-gnu/libnsl.so.1
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libnss_compat.so -> lib/x86_64-linux-gnu/libnss_compat.so.2
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libnss_dns.so -> lib/x86_64-linux-gnu/libnss_dns.so.2
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libnss_files.so -> lib/x86_64-linux-gnu/libnss_files.so.2
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libnss_hesiod.so -> lib/x86_64-linux-gnu/libnss_hesiod.so.2
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libnss_nis.so -> lib/x86_64-linux-gnu/libnss_nis.so.2
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libnss_nisplus.so -> lib/x86_64-linux-gnu/libnss_nisplus.so.2
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libpthread.so -> lib/x86_64-linux-gnu/libpthread.so.0
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libresolv.so -> lib/x86_64-linux-gnu/libresolv.so.2
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/librt.so -> lib/x86_64-linux-gnu/librt.so.1
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libthread_db.so -> lib/x86_64-linux-gnu/libthread_db.so.1
W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libutil.so -> lib/x86_64-linux-gnu/libutil.so.1

The library is shipped in /lib/$(DEB_HOST_MULTIARCH) and the .so
symlinks are shipped in /usr/lib/$(DEB_HOST_MULTIARCH):

lrwxrwxrwx root/root 0 2020-08-04 17:02 ./usr/lib/x86_64-linux-gnu/libBrokenLocale.so -> /lib/x86_64-linux-gnu/libBrokenLocale.so.1
lrwxrwxrwx root/root 0 2020-08-04 17:02 ./usr/lib/x86_64-linux-gnu/libanl.so -> /lib/x86_64-linux-gnu/libanl.so.1
lrwxrwxrwx root/root 0 2020-08-04 17:02 ./usr/lib/x86_64-linux-gnu/libdl.so -> /lib/x86_64-linux-gnu/libdl.so.2
lrwxrwxrwx root/root 0 2020-08-04 17:02 ./usr/lib/x86_64-linux-gnu/libmvec.so -> /lib/x86_64-linux-gnu/libmvec.so.1
lrwxrwxrwx root/root 0 2020-08-04 17:02 ./usr/lib/x86_64-linux-gnu/libnsl.so -> /lib/x86_64-linux-gnu/libnsl.so.1
lrwxrwxrwx root/root 0 2020-08-04 17:02 ./usr/lib/x86_64-linux-gnu/libnss_compat.so -> /lib/x86_64-linux-gnu/libnss_compat.so.2
lrwxrwxrwx root/root 0 2020-08-04 17:02 ./usr/lib/x86_64-linux-gnu/libnss_dns.so -> /lib/x86_64-linux-gnu/libnss_dns.so.2
lrwxrwxrwx root/root 0 2020-08-04 17:02 ./usr/lib/x86_64-linux-gnu/libnss_files.so -> /lib/x86_64-linux-gnu/libnss_files.so.2
lrwxrwxrwx root/root 0 2020-08-04 17:02 ./usr/lib/x86_64-linux-gnu/libnss_hesiod.so -> /lib/x86_64-linux-gnu/libnss_hesiod.so.2
lrwxrwxrwx root/root 0 2020-08-04 17:02 ./usr/lib/x86_64-linux-gnu/libnss_nis.so -> /lib/x86_64-linux-gnu/libnss_nis.so.2
lrwxrwxrwx root/root 0 2020-08-04 17:02 ./usr/lib/x86_64-linux-gnu/libnss_nisplus.so -> /lib/x86_64-linux-gnu/libnss_nisplus.so.2
lrwxrwxrwx root/root 0 2020-08-04 17:02 ./usr/lib/x86_64-linux-gnu/libpthread.so -> /lib/x86_64-linux-gnu/libpthread.so.0
lrwxrwxrwx root/root 0 2020-08-04 17:02 ./usr/lib/x86_64-linux-gnu/libresolv.so -> /lib/x86_64-linux-gnu/libresolv.so.2
lrwxrwxrwx root/root 0 2020-08-04 17:02 ./usr/lib/x86_64-linux-gnu/librt.so -> /lib/x86_64-linux-gnu/librt.so.1
lrwxrwxrwx root/root 0 2020-08-04 17:02 ./usr/lib/x86_64-linux-gnu/libthread_db.so -> /lib/x86_64-linux-gnu/libthread_db.so.1
lrwxrwxrwx root/root 0 2020-08-04 17:02 ./usr/lib/x86_64-linux-gnu/libutil.so -> /lib/x86_64-linux-gnu/libutil.so.1

Is it something not allowed anymore?

I know there are plans to (almost) empty /lib/ and move everything to
/usr/lib, but I am not sure we are there yet.

Thanks,
Aurelien


-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii binutils 2.35-1
ii bzip2 1.0.8-4
ii diffstat 1.63-1
ii dpkg 1.20.5
ii dpkg-dev 1.20.5
ii file 1:5.38-5
ii gettext 0.19.8.1-10
ii gpg 2.2.20-1
ii intltool-debian 0.35.0+20060710.5
ii libapt-pkg-perl 0.1.36+b3
ii libarchive-zip-perl 1.68-1
ii libcapture-tiny-perl 0.48-1
ii libclass-xsaccessor-perl 1.19-3+b5
ii libclone-perl 0.45-1
ii libconfig-tiny-perl 2.24-1
ii libcpanel-json-xs-perl 4.19-1
ii libdata-dpath-perl 0.58-1
ii libdata-validate-domain-perl 0.10-1
ii libdevel-size-perl 0.83-1+b1
ii libdpkg-perl 1.20.5
ii libemail-address-xs-perl 1.04-1+b2
ii libfile-basedir-perl 0.08-1
ii libfile-find-rule-perl 0.34-1
ii libfont-ttf-perl 1.06-1
ii libhtml-parser-perl 3.72-5
ii libio-async-loop-epoll-perl 0.21-1
ii libio-async-perl 0.77-3
ii libipc-run3-perl 0.048-2
ii libjson-maybexs-perl 1.004002-1
ii liblist-compare-perl 0.53-1
ii liblist-moreutils-perl 0.416-1+b5
ii liblist-utilsby-perl 0.11-1
ii libmoo-perl 2.004000-1
ii libmoox-aliases-perl 0.001006-1
ii libnamespace-clean-perl 0.27-1
ii libpath-tiny-perl 0.114-1
ii libperlio-gzip-perl 0.19-1+b6
ii libproc-processtable-perl 0.59-2
ii libsereal-decoder-perl 4.018+ds-1
ii libsereal-encoder-perl 4.018+ds-1
ii libtext-levenshteinxs-perl 0.03-4+b7
ii libtext-xslate-perl 3.5.8-1
ii libtime-duration-perl 1.21-1
ii libtime-moment-perl 0.44-1+b2
ii libtimedate-perl 2.3300-1
ii libtry-tiny-perl 0.30-1
ii libtype-tiny-perl 1.010002-1
ii libunicode-utf8-perl 0.62-1+b1
ii liburi-perl 1.76-2
ii libxml-libxml-perl 2.0134+dfsg-2
ii libxml-writer-perl 0.625-1
ii libyaml-libyaml-perl 0.82+repack-1
ii lzip 1.21-7
ii lzop 1.04-1
ii man-db 2.9.3-2
ii patchutils 0.4.2-1
ii perl [libdigest-sha-perl] 5.30.3-4
ii t1utils 1.41-4
ii unzip 6.0-25
ii xz-utils 5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
pn binutils-multiarch <none>
ii libtext-template-perl 1.59-1

-- no debconf information

Daniel Kahn Gillmor

unread,
Aug 19, 2021, 7:40:04 PM8/19/21
to
Control: affects 968525 + libgpg-error-dev libc6-dev
Control: found 968525 2.104.0
Control: retitle 968525 lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks, conflicts with lacks-unversioned-link-to-shared-library

On Mon 2020-08-17 00:00:07 +0200, Aurelien Jarno wrote:
> Since recent version of lintian, the following tags are reported against
> the libc6-dev package:
>
> W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libBrokenLocale.so -> lib/x86_64-linux-gnu/libBrokenLocale.so.1

I see the same issue in libgpg-error-dev with lintian 2.104.0. If I try
to fix it in libgpg-error-dev (i.e. by moving the symlink into lib/
instead of usr/lib), then instead i get a lintian warning
lacks-unversioned-link-to-shared-library, whose description reads in
part:

N: The symlink is generally expected in the same directory as the library
N: itself. The major exception to this rule is if the library is
N: installed in (or beneath) /lib, where the symlink must be installed in
N: the same dir beneath /usr.

So these two lintian tags appear to be in conflict!

--dkg
signature.asc

Daniel Kahn Gillmor

unread,
Aug 19, 2021, 9:00:03 PM8/19/21
to
Control: affects 968525 - libgpg-error-dev
Control: retitle 968525 lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

On Thu 2021-08-19 19:20:16 -0400, Daniel Kahn Gillmor wrote:
> I see the same issue in libgpg-error-dev with lintian 2.104.0. If I try
> to fix it in libgpg-error-dev (i.e. by moving the symlink into lib/
> instead of usr/lib),

hm, on further experimentation, i now take it back -- this warning
appeared in libgpg-error-dev because debian/rules in libgpg-error source
was manually adding an additional breakout-link. In particular, i think
for libgpg-error-dev the problem was that there was a link in lib/ that
was pointing to usr/lib/ (the other way around from what Aurelian
reported).

After removing the override_dh_link target in libgpg-error, lintian
doesn't complain about either breakout-link or
lacks-unversioned-link-to-shared-library

sorry for the additional confusion,

--dkg
signature.asc

Daniel Kahn Gillmor

unread,
Sep 16, 2021, 12:40:03 PM9/16/21
to
Control: affects 968525 + libgpg-error-dev

i'm now more confused than ever about this situation. Apparently,
clearing this lintian warning in libgpg-error introduced #992573 (a
grave bug) despite my testing it locally and it seeming to work (perhaps
my test was on a merged-/usr machine? i don't have the artifacts from
that test any longer to confirm).

The fact that silencing this warning in the expected way ended up
injecting a grave bug seems problematic. The test probably needs more
thought and fine-tuning.

--dkg
signature.asc

Felix Lechner

unread,
Sep 16, 2021, 7:10:03 PM9/16/21
to
Hi Daniel,

On Thu, Sep 16, 2021 at 9:39 AM Daniel Kahn Gillmor <d...@debian.org> wrote:
>
>
> The fact that silencing this warning in the expected way ended up
> injecting a grave bug seems problematic.

Isn't that an issue with the library paths in libgpg-error?

On sid, libgpg-error0_1.42-3_amd64.deb installs the shared library into /lib:

/lib/x86_64-linux-gnu/libgpg-error.so.0
/lib/x86_64-linux-gnu/libgpg-error.so.0.32.0

But the corresponding -dev installs the 'breakout-link' and the static
library into /usr/lib

/usr/lib/x86_64-linux-gnu/libgpg-error.so
/usr/lib/x86_64-linux-gnu/libgpg-error.a

I usually see all four files in the same directory. For my own
libwolfssl-dev—which is arguably much less used, if at all—the files
are all in /usr/lib:

/usr/lib/x86_64-linux-gnu/libwolfssl.a (from libwolfssl-dev)
/usr/lib/x86_64-linux-gnu/libwolfssl.so (from libwolfssl-dev)
/usr/lib/x86_64-linux-gnu/libwolfssl.so.24 (from libwolfssl24)
/usr/lib/x86_64-linux-gnu/libwolfssl.so.24.3.0 (from libwolfssl24)

Perhaps more significant, the Pkgconfig file for your libpg-error-dev
points consuming packages to /usr, but the shared libraries are
shipped in /lib:

$ more usr/lib/x86_64-linux-gnu/pkgconfig/gpg-error.pc
prefix=/usr
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${prefix}/lib/x86_64-linux-gnu
host=x86_64-pc-linux-gnu
mtcflags=
mtlibs=-pthread

Name: gpg-error
Description: GPG Runtime
Version: 1.42
Cflags:
Libs: -L${prefix}/lib/x86_64-linux-gnu -lgpg-error
Libs.private:
URL: https://www.gnupg.org/software/libgpg-error/index.html

When the link is dropped in an attempt to cure the Lintian tag [1]
Simon Josephson's build attempt of shishi [2] resorts to the static
version, which results—quite logically—in this relocation error:

/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libgpg-error.a <---
(libgpg_error_la-init.o): relocation R_X86_64_PC32 against symbol
`stderr@@GLIBC_2.2.5' can not be used when making a shared object;
recompile with -fPIC

What happens, please, if you ship the libraries in /usr/lib instead?
Alternatively, you could also ship the following link in /lib, move
the static library to /lib, and adjust the prefix in your Pkgconfig.

dh_link -plibgpg-error-dev
lib/$(DEB_HOST_MULTIARCH)/libgpg-error.so.0
lib/$(DEB_HOST_MULTIARCH)/libgpg-error.so

I am not familiar with all the intricacies of RPATH and related ld.so
features, but I am reading up on this blog page [3].

Kind regards
Felix Lechner

[1] https://salsa.debian.org/debian/libgpg-error/-/commit/7c408ba0968c14492b6f087c57c6d44af4878de6#8756c63497c8dc39f7773438edf53b220c773f67_34_33
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992573#5
[3] http://blog.tremily.us/posts/rpath/

Aurelien Jarno

unread,
Sep 16, 2021, 7:10:03 PM9/16/21
to
Hi Felix,

On 2021-09-16 15:56, Felix Lechner wrote:
> Hi Daniel,
>
> On Thu, Sep 16, 2021 at 9:39 AM Daniel Kahn Gillmor <d...@debian.org> wrote:
> >
> >
> > The fact that silencing this warning in the expected way ended up
> > injecting a grave bug seems problematic.
>
> Isn't that an issue with the library paths in libgpg-error?
>
> On sid, libgpg-error0_1.42-3_amd64.deb installs the shared library into /lib:
>
> /lib/x86_64-linux-gnu/libgpg-error.so.0
> /lib/x86_64-linux-gnu/libgpg-error.so.0.32.0
>
> But the corresponding -dev installs the 'breakout-link' and the static
> library into /usr/lib
>
> /usr/lib/x86_64-linux-gnu/libgpg-error.so
> /usr/lib/x86_64-linux-gnu/libgpg-error.a
>

Why is that supposed to be an issue? glibc has always been installed
like that.

Regards,
Aurelien

--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aure...@aurel32.net http://www.aurel32.net

Felix Lechner

unread,
Sep 16, 2021, 8:10:03 PM9/16/21
to
Hi Aurelien,

On Thu, Sep 16, 2021 at 4:00 PM Aurelien Jarno <aur...@debian.org> wrote:
>
> Why is that supposed to be an issue?

I do not know, but the relocation error shows that the shared library
installed in /lib by libgpg-error0 is not found unless
libgpg-error0-dev ships a "breakout" link in /usr/lib.

On my local system, /lib has precedence over /usr/lib:

$ more /etc/ld.so.conf.d/x86_64-linux-gnu.conf
# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

What reason could there be besides Pkgconfig for shishi's builder to
look only in /usr/lib?

> glibc has always been installed like that.

The analysis may not apply to Glibc. I do not see a Pkgconfig in
libc6-dev (and would have been surprised). Does Glibc recommend any
linker paths to consuming packages?

Kind regards
Felix Lechner

Felix Lechner

unread,
Sep 16, 2021, 8:50:02 PM9/16/21
to
Hi Daniel,

Sorry about the delayed response on this part.

On Thu, Aug 19, 2021 at 4:30 PM Daniel Kahn Gillmor <d...@debian.org> wrote:
>
> instead i get a lintian warning
> lacks-unversioned-link-to-shared-library

That is a very simple check. [1] Would you please include the full tag
context and a list of shipped files? The context mentions the expected
filename, which can be easily found in a shipping manifest (or not, in
your case).

There are two possible sources of bugs:

a) The expected file name is wrong. [2]
b) Lintian looks in the wrong folders. [3]

For (b) Lintian looks in the ld-config paths derived here [4] in part
from the multiarch path components found here. [5][6]

Kind regards
Felix Lechner

[1] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/SharedLibs.pm#L307-309
[2] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/SharedLibs.pm#L220-224
[3] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/SharedLibs.pm#L105
[4] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Data/Architectures.pm#L115
[5] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Data/Architectures.pm#L87
[6] https://salsa.debian.org/lintian/lintian/-/blob/master/data/architectures/host.json

Felix Lechner

unread,
Sep 16, 2021, 10:00:03 PM9/16/21
to
Hi Daniel,

On Thu, Sep 16, 2021 at 9:39 AM Daniel Kahn Gillmor <d...@debian.org> wrote:
>
> The fact that silencing this warning in the expected way ended up
> injecting a grave bug seems problematic.

It is an RPATH issue. I spotted '-rpath /usr/lib/x86_64-linux-gnu' in
the libtool invocation. [1]

Interestingly, the call to ./configure specified '--disable-rpath' but
was not successful. It seemed to resemble an issue in opendkim [2].
Perhaps this Debian doc about the topic [3] is helpful to you.

Kind regards
Felix Lechner

[1] https://salsa.debian.org/auth-team/shishi/-/jobs/1835930
[2] https://sourceforge.net/p/opendkim/bugs/189/
[3] https://wiki.debian.org/RpathIssue

Aurelien Jarno

unread,
Sep 19, 2021, 3:20:03 PM9/19/21
to
On 2021-09-16 16:56, Felix Lechner wrote:
> Hi Aurelien,
>
> On Thu, Sep 16, 2021 at 4:00 PM Aurelien Jarno <aur...@debian.org> wrote:
> >
> > Why is that supposed to be an issue?
>
> I do not know, but the relocation error shows that the shared library
> installed in /lib by libgpg-error0 is not found unless
> libgpg-error0-dev ships a "breakout" link in /usr/lib.

I guess I wasn't very clear. My question is why this new breakout-link
tag has been added, and how is this supposed to be an issue. Things have
been like that in the glibc package for 20 years, so I wonder why this
issue suddenly popped-up. I can't find anything in the Debian Policy
forbidding that.

Felix Lechner

unread,
Sep 19, 2021, 4:10:03 PM9/19/21
to
Hi Aurelien,

On Sun, Sep 19, 2021 at 12:15 PM Aurelien Jarno <aur...@debian.org> wrote:
>
> My question is why this new breakout-link tag has been added

The tag was implemented in response to Bug#243158. [1] I am not sure
about Yann's original suggestion, but I hope the tag is useful to
prevent links to /opt, for example.

Prior to Glibc, I encountered only packages in which links and shared
objects shared a parent folder.

Kind regards
Felix Lechner

[1] https://bugs.debian.org/243158

Aurelien Jarno

unread,
Sep 19, 2021, 6:20:04 PM9/19/21
to
On 2021-09-19 13:03, Felix Lechner wrote:
> Hi Aurelien,
>
> On Sun, Sep 19, 2021 at 12:15 PM Aurelien Jarno <aur...@debian.org> wrote:
> >
> > My question is why this new breakout-link tag has been added
>
> The tag was implemented in response to Bug#243158. [1] I am not sure
> about Yann's original suggestion, but I hope the tag is useful to
> prevent links to /opt, for example.

It seems to me that the original bug is about internal lintian bugs that
are not able to handle the symlinks.

> Prior to Glibc, I encountered only packages in which links and shared
> objects shared a parent folder.

Well there are a few other ones, libgpg-error-dev is one of them, even
if the number has decreased recently.

Now in the same spirit as in #993955, I am not sure you actually want to
push maintainers to move libraries from /lib to /usr/lib until there is
a clear plan for usrmerge and bookworm.

Also please note that even if fedora has finished the usrmerge
transition, they still ship glibc .so as a relative symlink to the
library in /lib.

Felix Lechner

unread,
Sep 19, 2021, 7:30:03 PM9/19/21
to
Hi,

On Sun, Sep 19, 2021 at 3:11 PM Aurelien Jarno <aur...@debian.org> wrote:
>
> Now in the same spirit as in #993955, I am not sure you actually want to
> push maintainers to move libraries from /lib to /usr/lib

The purpose of this tag was never to push people toward usr-merge. It
only looks like that to glibc and libgpg-error-dev because the
packages use mixed installation paths.

Furthermore, the comparison with Bug#993955 is not appropriate. Filed
at the extraordinary 'serious' level by a member of the release team,
it was based on the filer's misunderstanding of what the tag does and
when it was implemented: Introduced seven months ago as a
classification tag [1] it was never shown to users. The purpose was to
aid in the collection of statistics [2] that became then immediately
available via the JSON interface on the Lintian website. [3] The
description, too, was gentle boilerplate [4] and in line with
conventional wisdom at the time. Most significantly, the tag predated
the "considered harmful" thread on -devel [5] that commenced on July
15 by almost half a year.

Lintian's packaging hints never contradicted the consensus now
emerging—if that is what we have—either in that tag or in the
'breakout-link' tag being discussed here.

Maybe 'breakout-link' is not useful and we should get rid of it, but
it looks to me like we found an issue in the way libgpg-error or
Pkg-config invoke Libtool.

Kind regards
Felix Lechner

[1] https://salsa.debian.org/lintian/lintian/-/merge_requests/349#note_215066
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#168
[3] https://lintian.debian.org/query
[4] https://salsa.debian.org/lintian/lintian/-/blob/fe69b16048052be8ee35e0596cac7777fdcaff71/tags/u/unmerged-usr.tag
[5] https://lists.debian.org/debian-devel/2021/07/msg00126.html

Aurelien Jarno

unread,
Sep 20, 2021, 3:40:02 PM9/20/21
to
Hi,

On 2021-09-19 16:18, Felix Lechner wrote:
> Hi,
>
> On Sun, Sep 19, 2021 at 3:11 PM Aurelien Jarno <aur...@debian.org> wrote:
> >
> > Now in the same spirit as in #993955, I am not sure you actually want to
> > push maintainers to move libraries from /lib to /usr/lib
>
> The purpose of this tag was never to push people toward usr-merge. It
> only looks like that to glibc and libgpg-error-dev because the
> packages use mixed installation paths.
>
> Furthermore, the comparison with Bug#993955 is not appropriate. Filed
> at the extraordinary 'serious' level by a member of the release team,
> it was based on the filer's misunderstanding of what the tag does and
> when it was implemented: Introduced seven months ago as a
> classification tag [1] it was never shown to users. The purpose was to
> aid in the collection of statistics [2] that became then immediately
> available via the JSON interface on the Lintian website. [3] The
> description, too, was gentle boilerplate [4] and in line with
> conventional wisdom at the time. Most significantly, the tag predated
> the "considered harmful" thread on -devel [5] that commenced on July
> 15 by almost half a year.
>
> Lintian's packaging hints never contradicted the consensus now
> emerging—if that is what we have—either in that tag or in the
> 'breakout-link' tag being discussed here.

Don't get me wrong, I never said it was a way to push for usr-merge.
That said the only way to get rid of this warning is to move libraries
from /lib to /usr/lib, and as maintainers are encouraged to get their
packages lintian, this goes against the consensus.

This is therefore definitely not your intention, but the result is that
it still goes in that direction that we want to avoid until there is a
clear usr-merge plan for bookworm.

> Maybe 'breakout-link' is not useful and we should get rid of it, but
> it looks to me like we found an issue in the way libgpg-error or
> Pkg-config invoke Libtool.

Please do not rewrite the history. libgpg-error was working pretty fine
before the maintainer tried to get rid of this lintian warning,
obviously in the wrong way. Lintian didn't detect anything, it just
pushed for the maintainer to do a mistake.

In addition putting the library in /lib and the .so symlink in /usr/lib
is something done by all libraries that were need to boot the system
before we stopped supporting a separate /usr directory. Therefore it's
much more than libc6-dev and libgpg-error-dev as you imply. Here is the
current list:

comerr-dev
libaudit-dev
libauparse-dev
libbind-export-dev
libbrlapi-dev
libbz2-dev
libc6-dev
libcap-dev
libcap-ng-dev
libcgroup-dev
libdevmapper-dev
libeditreadline-dev
libeinfo-dev
libexpat1-dev
libext2fs-dev
libfuse3-dev
libfuse-dev
libgpg-error-dev
libiw-dev
libkeyutils-dev
liblvm2-dev
liblzma-dev
liblzo2-dev
libncurses-dev
libnfsidmap1
libnfsidmap-dev
libnss-ldap
libnutclient-dev
libnutscan-dev
libpam0g-dev
libparted-dev
libpcre3-dev
libprocps-dev
librc-dev
libreadline-dev
libselinux1-dev
libsepol1-dev
libsepol-dev
libtirpc-dev
libupsclient-dev
libzfslinux-dev
ntfs-3g-dev
ss-dev
zlib1g-dev
0 new messages