Bug 1216876 - libboost_system_legacy and libboost_thread_legacy break zypper
Summary: libboost_system_legacy and libboost_thread_legacy break zypper
Status: RESOLVED FIXED
Alias: None
Product: openSUSE Distribution
Classification: openSUSE
Component: Other (show other bugs)
Version: Leap 15.5
Hardware: x86-64 openSUSE Leap 15.5
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Adam Majer
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-11-03 21:38 UTC by Dimitrios Bouras
Modified: 2024-03-08 12:30 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitrios Bouras 2023-11-03 21:38:05 UTC
When upgrading libboost_system1 and libboost_thread1 and removing legacy version 1.66.0 completely, dependency solver correctly pulls in libboost_system_legacy-1.66.0-1.4.1.x86_64 and libboost_thread_legacy-1.66.0-1.4.1.x86_64 for zypper, but libboost_system.so.1.66.0 and libboost_thread.so.1.66.0 are installed under /usr/lib64/boost-legacy where they are not automatically picked up by ls.so. The result, of course, is that zypper is broken.

Ways to resolve:
1. ld.so needs to know about /usr/lib64/boost-legacy
2. libboost_*_legacy-1.66.0-1.4.1.x86_64 install libs under /usr/lib64

I personally prefer #2.
Comment 1 Stefan Hundhammer 2023-11-04 14:53:24 UTC
Package dependencies are almost NEVER a problem of YaST.

If you don't know what bug component to choose, please do not make it a problem of YaST; that's what "other" is there for.
Comment 2 Stefan Hundhammer 2023-11-04 14:58:58 UTC
[sh @ balrog] ~ 11 % osc maintainer -e libboost_thread1_66_0

Defined in project:  SUSE:SLE-15-SP2:Update
  bugowner of libboost_thread1_66_0 : 
   -

  maintainer of libboost_thread1_66_0 : 
   mstrigl@suse.com, -


[sh @ balrog] ~ 12 % osc maintainer -e libboost_system_legacy

Defined in project:  SUSE:SLE-15:Update
  bugowner of libboost_system_legacy : 
   -

  maintainer of libboost_system_legacy : 
   mstrigl@suse.com, -
Comment 3 Stefan Hundhammer 2023-11-04 15:00:20 UTC
Bugzilla doesn't want to accept mstrigl@suse.com, so that's wrong in OBS.
Comment 4 Adam Majer 2023-11-15 09:42:46 UTC
This is very wrong. The boost_legacy package is there for other reasons -- namely that SP2:GA was released with broken boost ABI and it's there to keep packages from pre-SP2 to keep working. It's not for system use. Zypper should not really try to pull it in because it's not installed in system paths.

System boost should come from the rebuilt one in SLE15-SP2:Update. Where did this go? boost 1.66 is not legacy boost - it's system boost for all SLE15 codestreams.

Also, there is no libboost_system1 -- it's libboost_system1_66_0.


> When upgrading libboost_system1 and libboost_thread1 and removing legacy version 1.66.0 completely,

How did this happen? Did you remove these manually?
Comment 5 Michael Andres 2023-11-15 10:28:50 UTC
(In reply to Adam Majer from comment #4)
> This is very wrong. The boost_legacy package is there for other reasons --
> namely that SP2:GA was released with broken boost ABI and it's there to keep
> packages from pre-SP2 to keep working. It's not for system use. Zypper
> should not really try to pull it in because it's not installed in system
> paths.

Dependency resolution is package content agnostic.

If the included libraries are not for public use, the package must not advertise them. It must exclude the paths by setting the %__elflib_exclude_path macro or __provides_exclude_from macro instead. 
See
https://rpm-software-management.github.io/rpm/manual/dependency_generators.html
Comment 8 Dimitrios Bouras 2023-11-16 19:25:43 UTC
(In reply to Adam Majer from comment #4)
> This is very wrong. The boost_legacy package is there for other reasons --
> namely that SP2:GA was released with broken boost ABI and it's there to keep
> packages from pre-SP2 to keep working. It's not for system use. Zypper
> should not really try to pull it in because it's not installed in system
> paths.
> 
> System boost should come from the rebuilt one in SLE15-SP2:Update. Where did
> this go? boost 1.66 is not legacy boost - it's system boost for all SLE15
> codestreams.
> 
> Also, there is no libboost_system1 -- it's libboost_system1_66_0.
> 
> 
> > When upgrading libboost_system1 and libboost_thread1 and removing legacy version 1.66.0 completely,
> 
> How did this happen? Did you remove these manually?

Adam, in order to compile a proxy server I needed for connecting to AWS Greengrass core devices from my host, I had to upgrade boost from 1.66.0 to 1.75.0. After I installed the 1.75.0 versions of all the boost components required, I decided to clean-up the 1.66.0 versions, manually (as I don't like having multiple versions of things, unless needed)

Since apparently zypper needs version 1.66.0 of libboost_system and libboost_thread, I would have expected to see the classic dependency warning "if you remove this you will break zypper" but didn't. So I happily removed these two along with all the rest from version 1.66.0, of course breaking zypper.

I hope it's clear now.
Comment 9 Adam Majer 2023-11-29 17:26:29 UTC
Fix submitted. It may take a few days to actually get released.
Comment 10 Maintenance Automation 2024-03-08 12:30:12 UTC
SUSE-RU-2024:0816-1: An update that has one fix can now be installed.

Category: recommended (moderate)
Bug References: 1216876
Sources used:
openSUSE Leap 15.5 (src): boost-legacy-base-1.66.0-150000.1.7.1
Legacy Module 15-SP5 (src): boost-legacy-base-1.66.0-150000.1.7.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.