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?
--
_______________________________________________
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
