FS#58947 - [boost-libs] Add all provided .so files to "provides" array

Attached to Project: Arch Linux
Opened by Martin L. (wuestengecko) - Saturday, 09 June 2018, 16:54 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 18 June 2018, 14:29 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
The current PKGBUILD for boost-libs (pkgbase boost) only lists libboost_context.so in its "provides" array. However, as boost regularly does soname bumps on updates, it would be beneficial to have all provided libraries listed in order to more easily spot possible incompatibilities, and to allow packages to depend on the version they were built against simply by listing the required libraries in their "depends" arrays.

Additional info:
boost-libs version 1.67.0-4 provides these libraries: 'libboost_atomic.so' 'libboost_chrono.so' 'libboost_container.so' 'libboost_context.so' 'libboost_contract.so' 'libboost_coroutine.so' 'libboost_date_time.so' 'libboost_fiber.so' 'libboost_filesystem.so' 'libboost_graph.so' 'libboost_graph_parallel.so' 'libboost_iostreams.so' 'libboost_locale.so' 'libboost_log.so' 'libboost_log_setup.so' 'libboost_math_c99.so' 'libboost_math_c99f.so' 'libboost_math_c99l.so' 'libboost_math_tr1.so' 'libboost_math_tr1f.so' 'libboost_math_tr1l.so' 'libboost_mpi.so' 'libboost_mpi_python.so' 'libboost_numpy.so' 'libboost_numpy27.so' 'libboost_numpy3.so' 'libboost_numpy36.so' 'libboost_prg_exec_monitor.so' 'libboost_program_options.so' 'libboost_python.so' 'libboost_python27.so' 'libboost_python3.so' 'libboost_python36.so' 'libboost_random.so' 'libboost_regex.so' 'libboost_serialization.so' 'libboost_signals.so' 'libboost_stacktrace_addr2line.so' 'libboost_stacktrace_basic.so' 'libboost_stacktrace_noop.so' 'libboost_system.so' 'libboost_thread.so' 'libboost_timer.so' 'libboost_type_erasure.so' 'libboost_unit_test_framework.so' 'libboost_wave.so' 'libboost_wserialization.so' 'mpi.so'

This list can also be dynamically generated at build time with a line at the end of the package_boost-libs() function like this:

provides=( $(find /usr/lib -type f -name '*.so' -printf '%f\n') )

Steps to reproduce:
1. Build and install any package that depends on a boost library, except libboost_context.so. An example is the icinga2 AUR package, which requires libboost_program_options.so, libboost_regex.so, libboost_system.so and libboost_thread.so.
2. Upgrade (or downgrade) the boost-libs package across a soname bump, e.g. 1.66.0-3 -> 1.67.0-4.
3. Notice that the built icinga2 binary is no longer able to find its libraries, and thus is unable to run. Icinga2 has to be rebuilt against the newer library versions.
This could have been avoided if pacman were able to see the soname bump, and notice that icinga2 would not be compatible with the newer versions. (Of course this also requires changes to icinga2's PKGBUILD.)
This task depends upon

Closed by  Doug Newgard (Scimmia)
Monday, 18 June 2018, 14:29 GMT
Reason for closing:  Won't implement
Comment by Doug Newgard (Scimmia) - Tuesday, 12 June 2018, 16:32 GMT
You realize how badly versioned deps, including sodeps are handled in the AUR, right?
Comment by Eli Schwartz (eschwartz) - Tuesday, 12 June 2018, 18:12 GMT
This was initially added due to  FS#51779  for the one cherry-picked lib. But we usually use rebuild lists for boost...
Comment by Martin L. (wuestengecko) - Wednesday, 13 June 2018, 13:53 GMT
@Doug Newgard actually no, I don't. The only real problem I can see is a versioned dependency somehow sneaking into .SRCINFO and confusing solvers. But as AUR helpers are officially unsupported anyways, that's not the problem of Arch devs. However I can't even see this happening, as the so-version deps are generated at build time, and things like `makepkg --printsrcinfo` have no way of knowing anything about that.

@Eli Schwartz maintaining a rebuild list sounds tedious, and even more so if you have no control over when new packages get pushed to the official repos. And really, taking care of dependencies and their versions is literally pacman's job. I still don't see why adding information about the libraries would be a bad thing.
Comment by Doug Newgard (Scimmia) - Wednesday, 13 June 2018, 14:03 GMT
The problem is that the versioned deps block any updates. In general, you have to uninstall the program with the versioned deps (and anything that depends on it), update, then rebuild and reinstall. You can get around this by building in a clean chroot and adding the package to a local repo, but that's not common.
Comment by Eli Schwartz (eschwartz) - Wednesday, 13 June 2018, 17:48 GMT
It's not tedious at all, we've done it numerous times already because we have to -- depending on pacman to solve this means we'll have uninstallable packages. Instead we, who are in fact in control of when new packages get pushed on account of we're the ones who push them, use a simple script on the build servers to check which packages link to any boost libraries, and rebuild them all.

Arch Linux does not support partial updates in the first place, why should boost be special?

$ printf %s\\n /usr/lib/lib*.so | wc -l
1123

That's a lot of libs that don't use libprovides.

This change seems wholly motivated by being able to catch AUR packages that aren't rebuilt. And AUR packages are the place this hurts the most, since unless you do like we do when building official packages and build in clean chroots, it becomes very difficult to update at all.
Comment by Martin L. (wuestengecko) - Friday, 15 June 2018, 11:50 GMT
chroot + local repo is exactly what I'm doing, and it works so great that I guess I simply forgot about the darker times before I had that setup. So yes, this isn't about partial upgrades at all, but finding AUR packages that have to be rebuilt - in that case I'd rather have pacman refuse to upgrade instead of having a broken package (even if it's not system-critical). But I can also see how this shouldn't be default behavior, and as it requires modifying PKGBUILDs anyway, I'll think of another solution that works for me.

So this request can be closed.
Comment by Eli Schwartz (eschwartz) - Friday, 15 June 2018, 12:21 GMT
It also requires convincing AUR maintainers to utilize depends=('libfoo.so')...

FWIW, you could try the lddd command from devtools. It greps all binaries/libraries on your system to see if ldd returns "not found" errors, then lists the packages that provide any/each broken things.

Loading...