On Tue, 9 Dec 2025 17:03:44 +0000
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
upstream has fixes available, I should be able to update codeblocks even
before your boost update
Dan
> 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?
>
> --
> _______________________________________________
> 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
--
_______________________________________________
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
