FR: some library packages rely on postint for proper dynamic resolution

[lazcamus]

Title is generic as I think other libs may do this too?

The specific example I'm dealing with today are packages libblas3 and liblapack3 that install their shared libraries into a subdirectory of the dynamic library path (e.x. /usr/lib/x86_64-linux-gnu/blas/libblas.so.3), then in post install run update-alternatives to make the symlinks in the library directory.

Postint:

% cat libblas3.postinst.in
#!/bin/sh

set -e

update-alternatives --install /usr/lib/@DEB_HOST_MULTIARCH@/libblas.so.3 \
                    libblas.so.3-@DEB_HOST_MULTIARCH@ /usr/lib/@DEB_HOST_MULTIARCH@/blas/libblas.so.3 10

#DEBHELPER#

exit 0

The binaries that try to load them fail. My testcase is installing gdal-bin and running ogr2ogr --version, which will cry:

root@d876f2ae9478:~# ogr2ogr --version                                                                                                                          
ogr2ogr: error while loading shared libraries: libblas.so.3: cannot open shared object file: No such file or directory

I'm currently hacking around it with symlinks:

# This is to hack around the fact that liblas3 and liblapack3 run a postinst to
# `update-alternates` and install their libraries in /usr/lib/$(uname -m)-linux-gnu/
#
# We don't run the postist, so just symlink the libraries to where they need to be
genrule(
    name = "libblas.symlinks_mtree",
    outs = ["libblas.symlinks.mtree"],
    # double $$ to pass through the bazel make rule expansion
    cmd = """
    for lib in libblas.so.3 liblapack.so.3; do
        DEB_HOST_MULTIARCH="$$(uname -m)-linux-gnu";
        LIBNAME="$${lib%%.so.*}"; LIBNAME="$${LIBNAME#lib}";
        echo "usr/lib/$$DEB_HOST_MULTIARCH/$$lib uid=0 gid=0 time=0 type=link link=/usr/lib/$$DEB_HOST_MULTIARCH/$$LIBNAME/$$lib"
    done > $@
    """,
)

tar(
    name = "libblas.symlinks",
    mtree = ":libblas.symlinks_mtree",
)

Filing the issue as an errata I guess, as I have a workaround in hand. Does this seem like a "best practice" for something like this? I don't really expect rules_distroless to handle this out of the box unless it was a common library pattern (and it doesn't seem to be).

[thesayyn]

We currently don't support running any lifecycle scripts as usually they require a running container, technically we could support lifecycle hooks that does basic things like these but i don't have the time do it myself, happy to review a PR

[thesayyn]

I have looked into this briefly, good news is that as we always install from scratch, we are not concerned with most of the lifecycle commands we might get away with only running post* hooks, and the bad news is that only way to know if a package has hooks is to inspect the control layer which only downloaded when requested by a target.

[lazcamus]

It's a hard thing to support generically for sure.

I'm just spitballing, but maybe there's a class of postinst_ functions that'll accept control files to process, and output a weird compat tarball?

For this update-alternatives use case:

postinst_update_alternatives(
    name = "update_alternatives",
    srcs = ["@noble//libblas3/arm64:control"]
)

# then include ":update_alternatives" in your `tars`

The rule could grab the postinst out of each of the sources, look for dh_installalternatives signature in postinst and spit out compatibility symlinks?

Kind elaborate ... but it's more generic than the ca-certificates munging.

[thesayyn]

update_alternatives is definitely something we can support, looks like its interface is well defined and something we can mimic.

I'd be happy review a PR and debate more on the code.

[froody]

@thesayyn would something like https://gist.github.com/froody/05a63c31f573307054b04fa358f457d2 be accepted? I'm using that in my tree and it works well for liblas + liblapack

[thesayyn]

Something along the lines of that would be fine yeah, possibly a new rule, that does these kinds of hacks.