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.