Bug 1211194 - lv2 upgrade fails due to file conflicts
Summary: lv2 upgrade fails due to file conflicts
Status: NEW
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Current
Hardware: Other Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Simon Lees
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-05-08 11:20 UTC by Fabian Vogt
Modified: 2023-12-19 01:30 UTC (History)
4 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 Fabian Vogt 2023-05-08 11:20:55 UTC
The following 2 packages are going to be upgraded:
  lv2        1.18.4-1.3 -> 1.18.10-2.1
  lv2-devel  1.18.4-1.3 -> 1.18.10-2.1

2 packages to upgrade.
Overall download size: 0 B. Already cached: 216.8 KiB. After the operation, 110.3 KiB will be freed.
Continue? [y/n/v/...? shows all options] (y): y
committing
In cache lv2-1.18.10-2.1.x86_64.rpm                                                                                                                                                                                           (1/2), 106.1 KiB    
In cache lv2-devel-1.18.10-2.1.x86_64.rpm                                                                                                                                                                                     (2/2), 110.8 KiB    

Checking for file conflicts: ..............................................................................................................................................................................................................[error]
Detected 9 file conflicts:

File /usr/include/lv2/atom/util.h
  from install of
     lv2-devel-1.18.10-2.1.x86_64 (Haupt-Repository (OSS))
  conflicts with file
     /usr/include/lv2/lv2plug.in/ns/ext/atom/util.h
  from install of
     lv2-devel-1.18.10-2.1.x86_64 (Haupt-Repository (OSS))

File /usr/include/lv2/core/attributes.h
  from install of
     lv2-devel-1.18.10-2.1.x86_64 (Haupt-Repository (OSS))
  conflicts with file
     /usr/include/lv2/lv2plug.in/ns/lv2core/attributes.h
  from install of
     lv2-devel-1.18.10-2.1.x86_64 (Haupt-Repository (OSS))

...

The reason for that is that old lv2-devel contains symlinks such as

/usr/include/lv2/ui -> ../../lib64/lv2/ui.lv2

while the new lv2-devel has them as directories with content inside:

/usr/include/lv2/ui
/usr/include/lv2/ui/ui.h

This is not supported by libzypp/libsolv/rpm.
Comment 1 Fabian Vogt 2023-05-08 11:32:44 UTC
While it is possible to use a %pre or %pretrans script to perform the symlink -> directory conversion, I'm not aware of a way to make the libzypp file conflicts check happy. Any idea?
Comment 2 Konstantin Voinov 2023-05-09 17:49:20 UTC
We can try to build with old_headers=false
Let's see.
Comment 3 Konstantin Voinov 2023-05-10 06:57:07 UTC
(In reply to Konstantin Voinov from comment #2)
> We can try to build with old_headers=false
> Let's see.

No. It breaks some (not even old) plugins build, at least https://github.com/sjaehn/
BTW some other apps have support for new headers https://github.com/Ardour/ardour/blob/b1a771d36bb3a4abd3670679686607837e92e43d/libs/ardour/ardour/uri_map.h#L30
Comment 4 Konstantin Voinov 2023-05-10 06:57:55 UTC
(In reply to Fabian Vogt from comment #1)
> While it is possible to use a %pre or %pretrans script to perform the
> symlink -> directory conversion, I'm not aware of a way to make the libzypp
> file conflicts check happy. Any idea?

I think we have to make some transitional package for that case.
Comment 5 Michael Andres 2023-06-28 11:19:53 UTC
(In reply to Fabian Vogt from comment #1)
> While it is possible to use a %pre or %pretrans script to perform the
> symlink -> directory conversion, I'm not aware of a way to make the libzypp
> file conflicts check happy. Any idea?

Not on the libzypp level. The file conflict check runs before any changes are made to the system. The check can not know whether there will be some script running to fix the issue before the package is extracted or not.

The actual check however is performed by libsolv. Michael(mls) would know if there is a way for a package to tell the issue should not be reported.
Comment 6 Michael Schröder 2023-06-29 08:43:22 UTC
Not really. You could %ghost one of the files but that's gonna be quite ugly. That's currently the only way I see in the libsolv code.
Comment 7 Konstantin Voinov 2023-12-19 01:30:19 UTC
So, we can't fix it until libsolv has a proper solution for that?
For me using %ghost here is worse than a manual reinstall of the package.