On Tue, Dec 9, 2025 at 12:04 PM Jonathan Wakely <[email protected]> wrote: > > I'm prepping a Boost update for rawhide and have discovered that the > libboost_system.so shared library is no longer installed by the latest > Boost release. Boost.System is now a header-only library, so there's > no shared library. > > In Fedora today we package libboost_system.so.1.83.0 in its own > boost-system subpackage, which is required by a handful of packages: > > anyterm > btbuilder > codeblocks > glob2 > lunchbox > lv2-c++-tools > prusa-slicer > python-graph-tool > snapper > systemtap > > I can easily fix those when doing the package rebuilds, but I'm unsure > how to handle the removal of the boost-system RPM which might affect > users who are consuming that RPM today. > > We could drop the boost-system subpackage completely, and add: > > Provides: boost-system %{version}-%{release} > Obsoletes: boost-system < 1.89.0 > > to every remaining subpackage in boost.spec, so that any user RPMs > that Require:boost-system will be able to satisfy that dependency by > installing any other boost RPM. That would solve the problem for > users' own RPMs, but would not help with makefiles that explicitly add > -lboost_system because those would now fail to link. > > Or we could keep the boost-system subpackage and mark it with: > > Provides: deprecated() > > and make it install a libboost_system.so file that prints a warning > when you link to it, similar to the one that glibc has for the 'gets' > symbol: > gets.c:(.text+0xa): warning: the `gets' function is dangerous and > should not be used. > > We could print: > system.cc:(.text+0xa): warning: the `libboost_system.so` library is a > stub and should not be used. > > Or we could just install an empty linker script as libboost_system.so > and mark it deprecated in the spec file, and then just remove it in > two releases time. But that seems like it won't actually warn users > that it's going away, and so has no real benefit compared to just > removing it now and adding the Provides: and Obsoletes: tags. > > What's the right way to do this? >
I'd go with Obsoletes and Conflicts without Provides. That way it gets removed on upgrade and can't be installed accidentally. It also makes it obvious that it's gone. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
