[arch-general] announce libraries in provides=()

mike lojkovic mikelojkovic at gmail.com
Thu May 16 12:30:25 UTC 2019

Suggesting pacman add some portage style features for dependency resolution
and packaging? Modifying packages on a local system to fix bugs caused by
versions of packages?

On Thu, May 16, 2019, 3:10 AM Erich Eckner via arch-general <
arch-general at archlinux.org> wrote:

> Hash: SHA256
> Hi,
> I would like to encourage adding provided libraries of a package to its
> "provides=()" array in the PKGBUILD.
> Some background:
> Updating the system libraries may break manually compiled packages. Having
> the version of the system libraries fixed in the dependencies of the
> manually compiled package, this could be avoided, because then pacman
> would refuse to replace the system library.
> The current behaviour can be annoying if the manually compiled package is
> vital (e.g. a mail server), requires some time for compilation and/or
> fails to build for unrelated reasons.
> If the libraries are added to the provides array, makepkg will
> automatically version those dependencies.
> libvorbis, for example has
> provides=('libvorbis.so' 'libvorbisenc.so' 'libvorbisfile.so')
> in the PKGBUILD which becomes
> Provides: libvorbis.so=0-64  libvorbisenc.so=2-64  libvorbisfile.so=3-64
> in the package.
> This way, external packages can pick up versioned dependencies on the
> library by using "depends=()".
> Since my proposal[1] got denied for a single package, I currently have a
> horrible hack in place which manually adds depends= entries in the
> package() function looking at the compiled binaries with objdump. Because
> I can only add dependencies based on the $pkgver of the package, but not
> on the soname version of the library, I have to recompile for each version
> change - not only the ones which actually change soname. The only current
> alternative would be to manually build the required libraries, too (with
> the provides=() entries added) - which is obviously also a bad idea.
> Can we please have a todo list of packages that provide libraries in
> /usr/lib but not announce them in the metadata?
> Or should we enable makepkg to automatically search through the library
> directory? (Probably not a good idea, as there might be differing
> locations, libraries which should deliberately not be announced, etc. ...)
> Or is my approach flawed from the beginning? How should I else circumvent
> breaking the linking?
> regards
> Erich Eckner
> 1] https://bugs.archlinux.org/task/61018
> e1r7Ag/7Ba4iTOHQ3r7qa9h1b9A+h9BGHlZ3lw4CYYR/hxI9lFWGDpL50KQot0Or
> FUs/07F4mdQsiwHWEgb9epQFG3EQ3Uxdj0fUjdOVTVgKR9Qr0Tn2qxq4dlfvU0LD
> IGIEc09xqEsvhNCgpGz0+Lr2P18JCadpTSn9RKELcYwNGG8IV+uThE6ovMH3BS51
> DfRv4ToSD23BV+tmsBP4eFWwK3Io87R2qzgcw0ulJAqG2BA0UkNXU3rM7SKogXT2
> uBeU7jTvlMtWIPcQ+pUCwyK+4PUwGrFrhVp2/s7pY/UA+Ve4S0asXLCc9YQqq8Ri
> ppByDnNaT4YM34aw67kgIOuKYElzYyoDVsmrbH1sHeAYZuSOG3ibmS0+gr0gLQCr
> U83E27SO+K60DxgNTtYcUdfnryCZbcqp+kDJmWh5MtRdwyBXajwSQasy+SU2ZYuR
> fvdAD7/8Q8KFniV4AIVehIEjGVhbavXqrc6zGC7UqonhzVFi9qZ9UoxPUomqzHAQ
> pFSHABPyL4RSH6IfLO28U3JKeBVxC9RyOwl+eqaPjWwmo6c0vlxyzIMdH9g83hnZ
> innbdlKnSFSNbV6kG+FqkuUYxFlR2lc0VicBVCh5ObpvLE8MscUP0ns+xxBxQW2c
> N4Xj6hGS8d6VtyDutf3E8zh2/rf+/jXuIkliZ/X3cei7eYAserA=
> =nrCB

More information about the arch-general mailing list