-----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
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@archlinux.org> 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-----
On Thu, May 16, 2019 at 3:23 PM mike lojkovic via arch-general < arch-general@archlinux.org> wrote:
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?
Arch Linux has always made it clear that partial upgrades are unsupported. I have had to do some hair-raising things to recover some systems after doing partial upgrades, but this perhaps may make all of our lives a bit easier. Even if their official stance on partial upgrades remains, it would at least a more sane safeguard against ending up in a system that can only be recovered by the guruest of gurus. (e.g. you upgraded glibc and nothing works any more, or you've broken pacman,...)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Thu, 16 May 2019, Andy Pieters wrote:
On Thu, May 16, 2019 at 3:23 PM mike lojkovic via arch-general < arch-general@archlinux.org> wrote:
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?
Arch Linux has always made it clear that partial upgrades are unsupported. I have had to do some hair-raising things to recover some systems after doing partial upgrades, but this perhaps may make all of our lives a bit easier. Even if their official stance on partial upgrades remains, it would at least a more sane safeguard against ending up in a system that can only be recovered by the guruest of gurus. (e.g. you upgraded glibc and nothing works any more, or you've broken pacman,...)
Hi,
don't get me wrong, I'm not proposing to add versioned dependencies on libraries to official arch packages, but to add the respective "provides" entries, so _unofficial_ packages can have versioned dependencies if they want.
What does "partial upgrade" mean in the context of a package compiled by the user?
regards, Erich
On Fri, May 17, 2019 at 11:55 AM Erich Eckner via arch-general < arch-general@archlinux.org> wrote:
What does "partial upgrade" mean in the context of a package compiled by the user?
Nothing much just daydreaming that if all packages have this user compiled or not...
On Thu, 16 May 2019 16:06:51 +0100 Andy Pieters arch-general@andypieters.me.uk wrote:
On Thu, May 16, 2019 at 3:23 PM mike lojkovic via arch-general < arch-general@archlinux.org> wrote:
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?
Arch Linux has always made it clear that partial upgrades are unsupported. I have had to do some hair-raising things to recover some systems after doing partial upgrades, but this perhaps may make all of our lives a bit easier. Even if their official stance on partial upgrades remains, it would at least a more sane safeguard against ending up in a system that can only be recovered by the guruest of gurus. (e.g. you upgraded glibc and nothing works any more, or you've broken pacman,...)
I was not suggesting partial upgrades; but, I suppose that feature would be come along as a result. I'm referring to the fact that using Quarry to manage Ruby packages installed caused an edge caused a naming issue with the main repos. There used to be ruby-unicorn on the arch repos, which has been renamed to ruby-unicorn-engine mainly out of Quarry pointing out issues with naming. So, ruby-unicorn is a ruby gem that does web server stuff, and ruby-unicorn in the official repos had something to do with hardware emulation. The ruby-unicorn in Quarry was using the proper ruby name for the package, while the arch repo one was using a different name for the their ruby gem.
So, I have to modify pacman.conf to keep the ruby-unicorn from Quarry installed, and I still receive warnings about the name change. Actually, I'll keep getting that warning if I install the properly named ruby-unicorn, according to the gems list. It would be nice to just modify the depenendencies locally.
arch-general@lists.archlinux.org