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@xxxxxxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > 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 > > -----BEGIN PGP SIGNATURE----- > > iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAlzcCZAACgkQCu7JB1Xa > 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 > -----END PGP SIGNATURE----- >