On 14/12/21 20:40, Emil Velikov wrote:
Hey Allan,
I really like the idea, although I might have spotted some gotchas.
On Sun, 12 Dec 2021 at 10:54, Allan McRae <[email protected]> wrote:
This patch series 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')
Considering your examples (below) also handle "cmd" and "pc" the
LIB_DIRS name is misleading. Alas no better suggestion comes to mind
ATM.
Not really... This is the path for adding library dependencies &
provides. If other autodeps get added, they may need their own
configuration option.
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
If I understand correctly, we create a mapping pretty-name:actual-path
in the makepkg.conf and use the pretty-name in PKGBUILD.
Do we add the pretty-name or actual-path in .PKGINFO?
That is the line from the .PKGINFO
provide = <tag>:<soname>
Does pacman
print these autodeps ... even if only for informational purposes?
They are treated the same as any provide or depend.
For example, using -Qi on my pacman-git package currently shows:
Provides : pacman=6.0.1 lib:libalpm.so.13
Depends On : archlinux-keyring bash curl gpgme libarchive
pacman-mirrorlist lib:libcurl.so.4
What is expected to happen if someone typos the existing mappings -
say "lib32:usr/lib23"? Or re-defines the standard ones
"lib:my/special/path"?
It their makepkg.conf has "lib32:usr/lib23" it is very likely that no
dependencies/provides will be added.
Are we going to continue or error out - is the error message going to
be meaningful or rather cryptic?
As above, nothing will happen. The usr/lib23 directory will (I guess)
never occur in a package, so never be searched for files with an soname.
I see this as being the same as any other configuration typo. e.g. if
MAN_DIRS pointed to non-existent places, no man pages would be compressed.
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.
I think the above questions might be the reason why Alpine chose to
keep them hard-coded. In particular, while this approach provides
flexibility, it leaves things open to various mistakes and misuse.
MAN_DIRS, DOC_DIRS, PURGE_TARGETS, ... all could have typos in their
configuration and not work.
Off the top of my head, we can enhance makepkg to catch most of those
issues. For example - we can use the actual-path in .PKGINFO,
explicitly check for mistakes/changes in the default mappings - lib,
lib32...
Although at this point one might as well have the defaults hardcoded in makepkg?
This needs to be configurable. e.g. some distros will have:
LIB_DIRS=('so:lib' 'so:usr/lib')
when they have not done a /usr merge.
Note, I selected the "so" prefix as being clearer for that example. I'm
thinking "so:usr/lib" and "so32:usr/lib32" might be better for the
configuration example.
The dependency/provides addotions can all be disabled in pacman.conf
with the '!autodeps' option.
s/addotions/additions/;s/pacman.conf/makepkg.conf/ typos?
Yes - I meant the OPTIONS array in makepkg.conf.
At a glance we can disable autodeps in the PKGBUILD itself, right?
Yes - it is can be specified in options=().
Thanks for the comments.
Allan
