Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1020113 > unrolled thread

Bug#737855: libnss3-dev: arch-dependent file in "Multi-Arch: same" package

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#737855: libnss3-dev: arch-dependent file in "Multi-Arch: same" package Helmut Grohne <helmut@subdivi.de> - 2020-08-02 10:30 +0200
    Bug#737855: libnss3-dev: arch-dependent file in "Multi-Arch: same" package Mike Hommey <mh@glandium.org> - 2020-08-02 22:50 +0200
      Bug#737855: libnss3-dev: arch-dependent file in "Multi-Arch: same" package Helmut Grohne <helmut@subdivi.de> - 2020-08-03 00:00 +0200
        Bug#737855: libnss3-dev: arch-dependent file in "Multi-Arch: same" package Mike Hommey <mh@glandium.org> - 2020-08-03 00:20 +0200
          Bug#737855: libnss3-dev: arch-dependent file in "Multi-Arch: same" package Helmut Grohne <helmut@subdivi.de> - 2020-08-03 09:30 +0200
            Bug#737855: libnss3-dev: arch-dependent file in "Multi-Arch: same" package Mike Hommey <mh@glandium.org> - 2020-08-03 22:40 +0200

#1020113 — Bug#737855: libnss3-dev: arch-dependent file in "Multi-Arch: same" package

[Multipart message — attachments visible in raw view] — view raw

Control: tags -1 + patch

On Wed, Jul 24, 2019 at 05:02:30PM +0800, Chen-Yu Tsai wrote:
> libpng-dev takes care of (or works around) this by disabling the
> --libdir feature of libpng-config, and removing the @libdir@ template.
> 
> Maybe the same could be done for libnss3-dev (and libnspr4-dev)?

I concur.

I checked that nss-config is the only file that breaks M-A:same (by
comparing all instances for all architectures). I also checked that the
--libdir support is the only reason for it to break M-A:same. Removing
the support is sufficient. There is no need for issuing
-L/usr/lib/<triplet> as that is on the default search path.

You can easily see on codesearch that nothing uses the --libdir option:
https://codesearch.debian.net/search?q=%28nss-config%7CNSS_CONFIG%29.*--libdir&literal=0

I'm attaching a removal patch. Please consider applying it. Applying it
also closes #963136.

Would you mind a NMU?

Helmut

[toc] | [next] | [standalone]

#1020217

On Sat, Aug 01, 2020 at 10:58:48PM +0200, Helmut Grohne wrote:
> Control: tags -1 + patch
> 
> On Wed, Jul 24, 2019 at 05:02:30PM +0800, Chen-Yu Tsai wrote:
> > libpng-dev takes care of (or works around) this by disabling the
> > --libdir feature of libpng-config, and removing the @libdir@ template.
> > 
> > Maybe the same could be done for libnss3-dev (and libnspr4-dev)?
> 
> I concur.
> 
> I checked that nss-config is the only file that breaks M-A:same (by
> comparing all instances for all architectures). I also checked that the
> --libdir support is the only reason for it to break M-A:same. Removing
> the support is sufficient. There is no need for issuing
> -L/usr/lib/<triplet> as that is on the default search path.
> 
> You can easily see on codesearch that nothing uses the --libdir option:
> https://codesearch.debian.net/search?q=%28nss-config%7CNSS_CONFIG%29.*--libdir&literal=0
> 
> I'm attaching a removal patch. Please consider applying it. Applying it
> also closes #963136.
> 
> Would you mind a NMU?

I'd rather replace nss-config with upstream's.

Mike

[toc] | [prev] | [next] | [standalone]

#1020222

Hi Mike,

On Mon, Aug 03, 2020 at 05:39:23AM +0900, Mike Hommey wrote:
> I'd rather replace nss-config with upstream's.

Please don't. That makes nss-config subtly buggy. The upstream
nss-config simply calls into pkg-config. In particular, it uses the
unqualified pkg-config. So the behaviour of nss-config becomes dependent
on the architecture you install pkg-config. In practice that means that
means when you install libnss3-dev for a foreign architecture, it will
be broken. And that amounts to breaking cross builds.

Really, using upstream's is the worst of choices here. Even removing
nss-config entirely would be better as that'd force dependent packages
(of which there are about 12) to properly use pkg-config instead.

So no, please don't use upstream's nss-config.

Helmut

[toc] | [prev] | [next] | [standalone]

#1020223

On Sun, Aug 02, 2020 at 11:50:11PM +0200, Helmut Grohne wrote:
> Hi Mike,
> 
> On Mon, Aug 03, 2020 at 05:39:23AM +0900, Mike Hommey wrote:
> > I'd rather replace nss-config with upstream's.
> 
> Please don't. That makes nss-config subtly buggy. The upstream
> nss-config simply calls into pkg-config. In particular, it uses the
> unqualified pkg-config. So the behaviour of nss-config becomes dependent
> on the architecture you install pkg-config. In practice that means that
> means when you install libnss3-dev for a foreign architecture, it will
> be broken. And that amounts to breaking cross builds.
> 
> Really, using upstream's is the worst of choices here. Even removing
> nss-config entirely would be better as that'd force dependent packages
> (of which there are about 12) to properly use pkg-config instead.

Upstream's nss-config uses pkg-config for 3 things:
- getting exec_prefix. It's always /usr, independently of the pkg-config
  you use
- getting includedir. It's always /usr/include/nss, independently of the
  pkg-config you use
- getting libdir. This varies dependending on the pkg-config you use,
  but so does the content of the current nss-config, and as was said
  up-thread, nothing uses that.

So really, using upstream's nss-config wouldn't break things more than
they currently are, while it would fix the immediate multi-arch problem.
All the while not breaking any reverse-dependency.

Mike

[toc] | [prev] | [next] | [standalone]

#1020249

Hi Mike,

On Mon, Aug 03, 2020 at 07:12:20AM +0900, Mike Hommey wrote:
> Upstream's nss-config uses pkg-config for 3 things:
> - getting exec_prefix. It's always /usr, independently of the pkg-config
>   you use
> - getting includedir. It's always /usr/include/nss, independently of the
>   pkg-config you use

Agreed.

> - getting libdir. This varies dependending on the pkg-config you use,
>   but so does the content of the current nss-config, and as was said
>   up-thread, nothing uses that.

Subtly wrong. The --libdir flag is not used by anything in Debian.
However the upstream nss-config --libs also emits:

    -Wl,-rpath-link,$libdir -L$libdir

So we are injecting a wrong library directory in some practical
situations. The rpath is a difference to the current nss-config. I
suspect that it alone would break stuff.

> So really, using upstream's nss-config wouldn't break things more than
> they currently are, while it would fix the immediate multi-arch problem.
> All the while not breaking any reverse-dependency.

It would break. Even natively. However with a one-line patch removing
the unnecessary -L flag and the rpath, I think we can reach agreement
here. Thank you for your persistence.

Do you want to implement this your self or would you prefer a patch?

Helmut

[toc] | [prev] | [next] | [standalone]

#1020440

On Mon, Aug 03, 2020 at 06:42:46AM +0200, Helmut Grohne wrote:
> Hi Mike,
> 
> On Mon, Aug 03, 2020 at 07:12:20AM +0900, Mike Hommey wrote:
> > Upstream's nss-config uses pkg-config for 3 things:
> > - getting exec_prefix. It's always /usr, independently of the pkg-config
> >   you use
> > - getting includedir. It's always /usr/include/nss, independently of the
> >   pkg-config you use
> 
> Agreed.
> 
> > - getting libdir. This varies dependending on the pkg-config you use,
> >   but so does the content of the current nss-config, and as was said
> >   up-thread, nothing uses that.
> 
> Subtly wrong. The --libdir flag is not used by anything in Debian.
> However the upstream nss-config --libs also emits:
> 
>     -Wl,-rpath-link,$libdir -L$libdir
> 
> So we are injecting a wrong library directory in some practical
> situations. The rpath is a difference to the current nss-config. I
> suspect that it alone would break stuff.

How so? a) it's not -rpath, and doesn't do something very relevant to
the produced binary except add a search path for dependencies of
dependencies b) LD happily ignores libraries it finds in the various
search paths when they are not for the right architecture.

The worst that happens is that you get warnings like:
/usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu/libnss3.so when searching for -lnss3

Mike

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web