Private libs end up in public provides

[xnox]

gcc-12-test-sca.yaml
package:
  name: gcc-12-test-sca
  version: 12.4.0
  epoch: 0
  description: "the GNU compiler collection - version 12"
  copyright:
    - license: GPL-3.0-or-later

environment:
  contents:
    packages:
      - busybox
      - gcc-12

pipeline:
  - runs: |
      mkdir -p ${{targets.destdir}}/usr/lib
      cp -r /usr/lib/gcc ${{targets.destdir}}/usr/lib

build output:

024/07/11 18:58:44 INFO generating package gcc-12-test-sca-12.4.0-r0
2024/07/11 18:58:44 INFO scanning for shared object dependencies...
2024/07/11 18:58:44 INFO   found lib libc.so.6 for usr/lib/gcc/x86_64-pc-linux-gnu/12.4.0/libgomp.so.1.0.0
2024/07/11 18:58:44 INFO   found lib libc.so.6 for usr/lib/gcc/x86_64-pc-linux-gnu/12.4.0/libitm.so.1.0.0
2024/07/11 18:58:44 INFO   found lib libm.so.6 for usr/lib/gcc/x86_64-pc-linux-gnu/12.4.0/libquadmath.so.0.0.0
2024/07/11 18:58:44 INFO   found lib libc.so.6 for usr/lib/gcc/x86_64-pc-linux-gnu/12.4.0/libquadmath.so.0.0.0
2024/07/11 18:58:44 INFO   found lib libc.so.6 for usr/lib/gcc/x86_64-pc-linux-gnu/12.4.0/libssp.so.0.0.0
2024/07/11 18:58:44 INFO scanning for commands...
2024/07/11 18:58:44 INFO scanning for pkg-config data...
2024/07/11 18:58:44 INFO scanning for python modules...
2024/07/11 18:58:44 INFO scanning for shbang deps...
2024/07/11 18:58:44 INFO   runtime:
2024/07/11 18:58:44 INFO     so:libc.so.6
2024/07/11 18:58:44 INFO     so:libm.so.6
2024/07/11 18:58:44 INFO   provides:
2024/07/11 18:58:44 INFO     so:libgomp.so.1=1
2024/07/11 18:58:44 INFO     so:libitm.so.1=1
2024/07/11 18:58:44 INFO     so:libquadmath.so.0=0
2024/07/11 18:58:44 INFO     so:libssp.so.0=0
2024/07/11 18:58:44 INFO   installed-size: 74429639
2024/07/11 18:58:44 INFO   data.tar.gz digest: f4370156bd67b791b8c0cb8eb0856a4a25a6a0301cad1f2ee85cfc26aa308e93
2024/07/11 18:58:44 INFO wrote packages/x86_64/gcc-12-test-sca-12.4.0-r0.apk

Expecting this to not happen:

2024/07/11 18:58:44 INFO   provides:
2024/07/11 18:58:44 INFO     so:libgomp.so.1=1
2024/07/11 18:58:44 INFO     so:libitm.so.1=1
2024/07/11 18:58:44 INFO     so:libquadmath.so.0=0
2024/07/11 18:58:44 INFO     so:libssp.so.0=0

As these libraries are in the private /usr/lib/gcc/ location, these are not public libraries and should not conflict with gcc which ships them publically. As intention is for gcc-12 to be co-installable with gcc.

Seems like we check for usr/lib/ prefix, but then we have unlimited depth, and subdirs shouldn't typically be included in automatic SCA provides as typically they are outside of the ldconfig.conf paths.

(cc @smoser @imjasonh @jonjohnsonjr )

[xnox]

This bug is the reason why gcc-12 package uses no-provides which intern is buggy w.r.t. turning of depends, see https://github.com/chainguard-dev/melange/issues/1366

[imjasonh]

Do you have an idea how many packages list a provides: so: that's "private" today?

(Is "private" here being defined as being under a subdirectory in /usr/lib?)

[smoser]

Maybe this is helpful. Maybe not. I put together this crappy shell script https://gist.github.com/smoser/0a11e2643b884960c1e5349d4dc0b8c7 .

I'm going to attach the output in case you find it useful. out.d.tar.gz

more crappy shell scripts with that data can answer your question.

[imjasonh]

Just checking my understanding: another example of this is py3-seaborn which has

-rwxr-xr-x root/root    249696 2024-01-26 10:15 usr/lib/python3.12/site-packages/numpy.libs/libquadmath-96973f99.so.0.0.0

and so has it in its provides:

provides = so:libquadmath-96973f99.so.0.0.0=0.0.0

https://apk.dag.dev/https/packages.wolfi.dev/os/x86_64/py3-seaborn-0.13.2-r0.apk@sha1:6d5ff93ebf4f34a98d67ca94f2c073f98832f57e/.PKGINFO

It sounds like that should be detected as a "vendored" .so, and not as a provided one. Is that right?

[smoser]

It sounds like that should be detected as a "vendored" .so, and not as a provided one. Is that right?

I agree with your 'vendored' statement.

It feels to me like we should only generate provides: for .so files in "normal" locations... those that we would put in /etc/ld.so.conf or /etc/so.conf.d/ . If something had a dependency on libquadmath above, then it is extremely unlikely that py-seaborn would successfully provide it.

I feel like there are probably some cases where that is not true, but i would expect those to be outliers. I can imagine that

• within the same origin package , things might "know" to look in additional paths
• for some well defined/well known plugin architectures there might be paths that are not expected to be added to system search path.

[xnox]

py3-seaborn => shouldn't really vendor in numpy, and should really depend on matching py3-numpy. Also our libquadmath currently is not correctly shipped by gcc as a separate package, as that really out to be a separate package for things to depend on at runtime (as in py3-numpy likely should have dependency on so:libquadmath.so which is provided by libquadmath package which is currently empty, because bugs).

[murraybd]

I'm closing this with the impression that https://github.com/chainguard-dev/melange/pull/1372 fixed it. If I'm wrong please reopen it and let me know!