[PATCH] Replace libdepends/libprovides

[Allan McRae]

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 <allan at archlinux.org> 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