Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Reference: https://reuse.software/

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

To select SONAMES that match a glob pattern, we want to use the
soname-match mode, not the soname mode.

Spotted by @LuigiPiucco on
<https://github.com/NixOS/nixpkgs/issues/100655

>.

Thanks: Luigi Sartor Piucco
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

The Debian 11 toolchain produces them like this.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Clear Linux patches glibc to put ld.so.cache in /var/cache/ldconfig/
to meet their goal of /etc being initially empty and reserved for the
sysadmin. We can handle this just like the conventional path: it
doesn't need to be architecture-specific.

Partially addresses
https://github.com/ValveSoftware/steam-runtime/issues/345

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

The File::Glob module in Ubuntu 12.04 'precise', and therefore also
Steam Runtime 1 'scout', doesn't support named keywords like this.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

I'm using Exherbo as an example of a host OS with an unusual layout that
breaks libcapsule's assumptions. Tested in an x86_64 Docker container, but
i386 is symmetrical and should also work.  This also puts the framework
in place to deal with other distributions' architecture-specific ld.so
caches.
Signed-off-by: Simon McVittie <smcv@collabora.com>

This is mostly just a simplification; it also improves the error
handling a little.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Exherbo uses the traditional-cross-compilation-style prefix,
/usr/<tuple>, which broke the tests' assumptions.
Signed-off-by: Simon McVittie <smcv@collabora.com>

This avoids worrying about which SONAME we're dealing with, and is
maybe more common in smallish containers (in particular Exherbo's
Docker container has it, which was useful for testing).
Signed-off-by: Simon McVittie <smcv@collabora.com>

I'm using Exherbo as an example of a host OS with an unusual layout
that breaks libcapsule's assumptions, in order to get the framework
in place for being able to receive patches from other weirder host OSs.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

The debug symbols for libcapsule-tools-relocatable would be the same as
for libcapsule-tools, making them non-co-installable. Use the environment
variable instead of --no-automatic-dbgsym for compatibility with
Steam Runtime 1 'scout', which is too old to have that option.
Signed-off-by: Simon McVittie <smcv@collabora.com>

If you don't want to change the link target for all the symlinks that
will be created, instead of using `--link-target`, it is now possible to
use the new `--remap-link-prefix` and just list the directories that
should be located under a different target.
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>

This can be used when we want to test some particular cases that we
expect should not succeed.
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

If we have the CAPTURE_FLAG_IF_EXISTS option flag, we should not
propagate an error if we are not able to find some dependencies of a
library. Instead we should just skip it.

This fixes an error that some users reported because they had some
leftovers unused libraries in their system and libcapsule reported an
error while trying to capture their (missing) dependencies.
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

If we `make dist` with gtk-doc-tools 1.28 from Debian 10 'buster' (the
current stable release), it generates a libcapsule-docs.xml in which
generation of tree_index.sgml is mandatory. This is incompatible with
building this non-GObject library with gtk-doc-tools >= 1.30, in which
tree_index.sgml is only generated if the library contains at least one
GObject type.

Most projects treat the libcapsule-docs.xml generated by gtk-doc as
a template and commit it to git, but in this project we don't
particularly want to maintain it and would prefer to keep regenerating
it during build.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>

We are now able to list the symbol versions and/or symbols that are
known to be public/private.

This is especially useful for comparing libraries that removed symbol
versions, or symbols, from one release to another. As this already
happened multiple times in the past, like for example with
`libdrm_nouveau.so.2` or `libedit.so.2`.
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

This is mainly to give me a version number I can use in other packages'
dependencies.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

This gives capsule-capture-libs a source of library-specific knowledge.
For example, if we know that:

  * libgcc_s.so.1 is installed with an unhelpful name, but it uses
    versioned symbols the way you'd hope;
  * libdbus-1.so.3 is installed with a helpful libtool-style name,
    but has private symbols that defeat our current simplistic
    comparisons

then we can express that as:

    [Library libgcc_s.so.1]
    CompareBy=versions;symbols;

    [Library libdbus-1.so.3]
    CompareBy=name;

A runtime that contains a known set of libraries would be a good place
to put library-specific knowledge about those libraries. For example,
the maintainers of the Steam Runtime know what libraries it contains,
and are well-placed to compare those libraries with their counterparts
in mainstream distributions.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

This will let us select the comparator to use for individual libraries.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Instead of asserting that the default behaviour is as desired, we now
assert that --compare-by=versions,name,symbols behaves the way it ought
to, and that the default behaviour is unchanged. It looks as though
applying --compare-by=versions,name,symbols indiscriminately could break
more than it fixes.
Signed-off-by: Simon McVittie <smcv@collabora.com>

This is primarily useful for testing and experimenting. Using versions
by default in preference to filenames (--compare-by="versions,name")
looks like it might be viable, but is a destabilising change that we
should test more before considering a change of defaults.

Meanwhile, counting symbols as a fallback (--compare-by="...,symbols")
does not look as safe as we had hoped, because if a library maintainer
has cleaned up their ABI by hiding private symbols without adding any
new symbols, we will sort libraries in exactly the wrong order - and
in reality, that seems to be what has happened in several libraries,
for example libX11.so.6 and libXfixes.so.3.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>