On 2021-12-13 18:35 +1000 Allan McRae via arch-dev-public wrote:
Hi all,
I submitted a patchset to pacman that I would like some packager feed-back on. [1]
Essentially this replaces the old libdepends/libprovides system into something akin to that used by APK. In short, makepkg.conf will have a variable like:
LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32')
At the end of package building, makepkg will look in the library directories and add a provide. E.g. for pacman:
provide = lib:libalpm.so.13
Note the prefix matches the prefix given to the relevant directory in LIB_DIRS. Similarly, makepkg can add dependencies on libraries. E.g. pacman may have:
depends = lib:libgpgme.so.11
Note, to help with bootstrapping this system, or if packages just do not want to add libprovides, the depends entries are only added if a package actually provides them.
This is different to the APK system for libraries which uses "so" as the prefix and is not configurable. But Alpine used musl, which has no concept of multilib, so we need to be a bit more flexible. Note the "lib" and "lib32" prefixes are just for discussion. Arch can configure how they want.
The dependency/provides additions can all be disabled in pacman.conf with the '!autodeps' option.
Note that APK has similar things for binaries and pkg-config files. e.g. provides = cmd:pacman provides = pc:libalpm
These can now be readily be added as dropins to libmakepkg.
Any opinions on this would be greatly appreciated. Is this a better system than the current one? Is adding automatic dependencies against the spirit of makepkg where everything is in the PKGBUILD?
Thanks, Allan
[1] https://gitlab.archlinux.org/pacman/pacman/-/commits/allan/autodeps
Is it necessary to hard-code LIB_DIRS with prefixes in each PKGBUILD that provides them? It seems simpler to me to use the standard library paths for the system with optional overrides in makepkg.conf. Makepkg could then scan those directories in the pkgdir, check the architecture of any shared objects and automatically add the prefixed provides (with the prefixes also configurable in makepkg.conf). Basically, any shared objects installed to system paths are effectively provided by the package anyway so they may as well all be included in the array so that packages can explicitly depend on them as packagers please. Any shared objects installed elsewhere are effectively invisible except for packages that specifically look for them in non-standard locations, but then it makes more sense to have a direct dependency on the package itself, with a version specification if necessary. On the depends side, the shared objects used by the package can also be scanned but it's obviously not as straight-forward to determine whether dependencies are general, versioned or even optional. A tool could be used to generate a list or prompt the package interactively to select relevant so deps to add to the package. Guidelines could be provided by the tool itself to avoid overspecification. It would be a shame if this led to a permanent dependency hell of packages depending explicitly on old versions even when not necessary. As for extending this to other dependency types such as commands, I wonder if cmd:name would be specific enough. It's rare but sometimes unrelated commands can have the same name. Some sort of unique identifier may be required. I only mention it in case it should be considered for generalizing the syntax now before settling on a final format. Possibly something like "prefix:identifier/object", where "identifer/" is optional. So you would have "cmd:unique_cmd" for something unique but "cmd:foo/common_cmd" for some generic fungible common_cmd provided by different packages when a conflicting common_cmd exists in another package. How would this syntax work for optional deps btw? Also, if this is added, it would be useful to have an option to display the provider package of such deps in the output of pacman -Qi (e.g. -Qii).