[pacman-dev] [RFC] pacman, package introspection, and managing linking

[Simon Gomizelj]

So, this started off as a what-if and I have a sort of proof of concept
working.

It be cool if pacman tracked the required and provided sonames.  Now
I realize that versioned deps have been discussed and decided against,
but tracking these lower level dependencies could provide some
additional and useful information to the database.

It is actually possible to do this fully automatically. I hacked
together this: <https://github.com/vodik/pkgelf>. Its a tool that can
recursively introspect a directory or a built package and dump out all
the needed libraries and provided sonames.

A quick example, inspecting libpulse-4.0-2-x86_64.pkg.tar.xz yeilds
this:

    REQUIRE libasyncns.so=0-64
    REQUIRE libc.so=6-64
    REQUIRE libdbus-1.so=3-64
    REQUIRE libdl.so=2-64
    REQUIRE libglib-2.0.so=0-64
    REQUIRE libjson-c.so=2-64
    REQUIRE libm.so=6-64
    REQUIRE libpthread.so=0-64
    REQUIRE librt.so=1-64
    REQUIRE libsndfile.so=1-64
    REQUIRE libxcb.so=1-64
    PROVIDE libpulse-mainloop-glib.so=0-64
    PROVIDE libpulse-simple.so=0-64
    PROVIDE libpulse.so=0-64

The elf parsing does not bring in much code or any extra dependencies.
Elf.h itself is part of glibc.

Having pacman aware of linkage can allow us to do a few cool things:

- Have pacman refuse operations when linkages would break. If one
  library provides libfoo=4 and an update replaces it with libfoo=5 but
  some package on the system still needs version 4, pacman warn the user
  of the breakage or refuse to do the update.
- Allowing PKGBUILD writers to verify they're not missing dependencies;
  if a package is found requires a soname that's not in the depends
  array, the author can be warned
- Aid in rebuilding. It be possible, theoretically, to check what needs
  to be rebuilt immediately. Probably especially useful in the case of
  building lots of packages from -git when upstream bumps the soname.

Now I realize there are a few caveats:

sodepends/soprovides puts entries in the depends/provides field. I don't
think this is appropriate, especially if this is done automatically.
Also not every package will have this information available. I think its
best to have it as additional information that could provide pacman with
hints. Pacman should continue to work as it currently does so long as
provides/requires is fulfilled, whether or not the linkage information
is consistent (after all, maybe its just missing from the package).

Also pacman supports Mac OS X as a platform, so pacman can't run under
the assumption that the binaries to deals with are ELF based.

So I'd propose that instead of adding this information to the existing
`provides` and `requires` fields in the `desc` db entry, maybe a new
entry should be added for linkage information, say one called `elf`. Old
versions of pacman will ignore the entry, newer versions can take
advantage of the information.

For example, libpulse-4.0-2-x86_64/elf could look like this:

    %NEEDED%
    libasyncns.so=0-64
    libc.so=6-64
    libdbus-1.so=3-64
    libdl.so=2-64
    libglib-2.0.so=0-64
    libjson-c.so=2-64
    libm.so=6-64
    libpthread.so=0-64
    librt.so=1-64
    libsndfile.so=1-64
    libxcb.so=1-64

    %SONAME%
    libpulse-mainloop-glib.so=0-64
    libpulse-simple.so=0-64
    libpulse.so=0-64

Pacman could also automatically detect if it should be using the ELF
support extensions by querying itself to see if it was compiled as an
ELF binary.