Zypper dup...how to handle file conflicts? in my case: /usr/lib64/gstreamer-1.0/libgstfaad.so

English Install/Boot/Login
1

Earlier today I ran sudo zyper ref and then

sudo zypper dup
[...]
File /usr/lib64/gstreamer-1.0/libgstfaad.so
  from install of
     gstreamer-plugins-bad-1.26.2-2.1.x86_64 (openSUSE-Tumbleweed-Oss)
  conflicts with file from install of
     gstreamer-plugins-bad-codecs-1.26.2-1699.1.pm.5.x86_64 (Packman)

some info:

zypper lr -d                                                                                                                                8 ✘  1m 7s   18:41:30  
#  | Alias               | Name                                   | Enabled | GPG Check | Refresh | Keep | Priority | Type   | URI                                | Service
---+---------------------+----------------------------------------+---------+-----------+---------+------+----------+--------+----------------------------------------------------------------------------------------+--------
 1 | X11_Wayland         | X11:Wayland                            | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | https://download.opensuse.org/repositories/X11:/Wayland/openSUSE_Tumbleweed/           |
 2 | code                | Visual Studio Code                     | Yes     | (r ) Yes  | No      | -    |   99     | rpm-md | https://packages.microsoft.com/yumrepos/vscode                                |
 3 | graphics            | graphics                               | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | https://download.opensuse.org/repositories/graphics/openSUSE_Tumbleweed/               |
 4 | openSUSE-20241028-0 | openSUSE-20241028-0                    | No      | ----      | ----    | -    |   99     | rpm-md | hd:/?device=/dev/disk/by-id/usb-TOSHIBA_TransMemory_0022CFF6BE23C1B0B126DEFB-0:0-part1 |
 5 | packman             | Packman                                | Yes     | (r ) Yes  | Yes     | -    |   70     | rpm-md | https://ftp.fau.de/packman/suse/openSUSE_Tumbleweed/                                |
 6 | repo-debug          | openSUSE-Tumbleweed-Debug              | No      | ----      | ----    | -    |   99     | N/A    | http://download.opensuse.org/debug/tumbleweed/repo/oss/                                |
 7 | repo-non-oss        | openSUSE-Tumbleweed-Non-Oss            | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | http://download.opensuse.org/tumbleweed/repo/non-oss/                                |
 8 | repo-openh264       | Open H.264 Codec (openSUSE Tumbleweed) | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed                                |
 9 | repo-oss            | openSUSE-Tumbleweed-Oss                | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | http://download.opensuse.org/tumbleweed/repo/oss/                                |
10 | repo-source         | openSUSE-Tumbleweed-Source             | No      | ----      | ----    | -    |   99     | N/A    | http://download.opensuse.org/source/tumbleweed/repo/oss/                               |
11 | repo-update         | openSUSE-Tumbleweed-Update             | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | http://download.opensuse.org/update/tumbleweed/                                |
12 | security            | security                               | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | https://download.opensuse.org/repositories/security/openSUSE_Tumbleweed/               |
13 | sublime-text        | Sublime Text - x86_64 - Stable         | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | https://download.sublimetext.com/rpm/stable/x86_64                                |
14 | utilities           | utilities                              | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | https://download.opensuse.org/repositories/utilities/openSUSE_Factory/                 |
15 | vivaldi             | vivaldi                                | Yes     | (r ) Yes  | Yes     | -    |   99     | rpm-md | https://repo.vivaldi.com/archive/rpm/x86_64

Often, people recommend to check whether a package is orphaned, in my case it is not:

zypper packages --orphaned                                                                                                                              ✔  18:41:38  
Loading repository data...
Reading installed packages...
S  | Repository | Name                            | Version                 | Arch
---+------------+---------------------------------+-------------------------+-------
i+ | @System    | copyq                           | 10.0.0+git7.f37d361-6.9 | x86_64
i  | @System    | copyq-bash-completion           | 9.1.0+git22.d56b22f-4.7 | noarch
i  | @System    | copyq-lang                      | 10.0.0+git7.f37d361-6.9 | noarch
i+ | @System    | libaquamarine6                  | 0.7.2-1.2               | x86_64
i  | @System    | libhyprutils4                   | 0.5.2-15.6              | x86_64
i  | @System    | libkdecorations3private1        | 6.3.1-1.1               | x86_64
i  | @System    | libpoppler146                   | 25.02.0-1.2             | x86_64
i  | @System    | libpoppler147                   | 25.03.0-1.1             | x86_64
i+ | @System    | libSPIRV-Tools-2025_2_rc2       | 2025.2~rc2-1.1          | x86_64
i+ | @System    | libSPIRV-Tools-2025_2_rc2-32bit | 2025.2~rc2-1.1          | x86_64
i  | @System    | libwx_baseu-suse14_0_0          | 3.2.6-4.2               | x86_64
i  | @System    | libwx_baseu_xml-suse14_0_0      | 3.2.6-4.2               | x86_64
i  | @System    | libwx_gtk2u_core-suse14_0_0     | 3.2.6-4.1               | x86_64
i  | @System    | libwx_gtk3u_aui-suse14_0_0      | 3.2.6-4.2               | x86_64
i  | @System    | libwx_gtk3u_core-suse14_0_0     | 3.2.6-4.2               | x86_64
i  | @System    | libwx_gtk3u_html-suse14_0_0     | 3.2.6-4.2               | x86_64
i  | @System    | libwx_gtk3u_richtext-suse14_0_0 | 3.2.6-4.2               | x86_64
i  | @System    | libx265-209                     | 3.6-1699.2.pm.12        | x86_64
i  | @System    | libx265-209-32bit               | 3.6-1699.2.pm.12        | x86_64
i+ | @System    | rmlint                          | 2.10.2-5.45             | x86_64

Since I honestly have no idea how to proceed, maybe someone can throw me some pointers?
Thanks!

2

I just deleted the Packman version. Everything seems fine so far.

3

I see the same here, the conflict arises trying to upgrade gstreamer-plugins-bad and gstreamer-plugins-bad-codecs-1.26.2-1699.1.pm.4.x86_64 from Packman to the next version gstreamer-plugins-bad-codecs-1.26.2-1699.1.pm.5.x86_64.
I would lock those packages until we understand what is going on: zypper al gstreamer-plugins-bad*.
Deleting the Packman version means that you cannot revert to the old one if you find that you need it (unless you have other means, e.g. a previous snapshot, to recover it).

4

I typically use the --allow-vendor-change switch - some of these packages bounce back and forth between OSS and packman on occasion.

I wouldn’t be inclined to lock it, because then if there’s an update in packman, you have to remember to unlock it before that update will apply.

2 Likes
5

The origin of the problem is an update to gstreamer-plugins-bad:

==== gstreamer-plugins-bad ====
Subpackages: gstreamer-plugins-bad-lang libgstadaptivedemux-1_0-0 libgstanalytics-1_0-0 libgstbadaudio-1_0-0 libgstbasecamerabinsrc-1_0-0 libgstcodecparsers-1_0-0 libgstcodecs-1_0-0 libgstcuda-1_0-0 libgstinsertbin-1_0-0 libgstisoff-1_0-0 libgstmpegts-1_0-0 libgstmse-1_0-0 libgstphotography-1_0-0 libgstplay-1_0-0 libgstplayer-1_0-0 libgstsctp-1_0-0 libgsttranscoder-1_0-0 libgsturidownloader-1_0-0 libgstva-1_0-0 libgstvulkan-1_0-0 libgstwayland-1_0-0 libgstwebrtc-1_0-0 libgstwebrtcnice-1_0-0

- Move faad plugin to main package.

(see New Tumbleweed snapshot 20250702 released! )
while Packman still includes the faad plugin in gstreamer-plugins-bad-codecs.
Removing the Packman package will remove other codecs as well, for instance:

LT-B:~ # zypper info --provides gstreamer-plugins-bad-codecs-1.26.2-1699.1.pm.5
<snip>
    libgstde265.so()(64bit)
    libgstfaac.so()(64bit)
    libgstfaad.so()(64bit)
    libgstopenaptx.so()(64bit)
    libgstrtmp.so()(64bit)
    libgstx265.so()(64bit)
<snip>

so generally speaking that doesn’t look as a good idea. Better lock and wait for Packman to catch up?

6

If you do not care which packages you use, why bother with vendor switch to start with.

7

An update to version 1.26.3 is in the pipeline ( see https://build.opensuse.org/package/revisions/multimedia:libs/gstreamer-plugins-bad )
so we should see a new lineup in a few days.

8

I generally don’t see any issues when I do this, and this keeps me on the ‘latest’ version.

This was a pretty common practice with the Mesa packages.

If there’s a reason not to do it, please share it - that would be more helpful than sitting in judgement of what other people do. :slight_smile:

1 Like
9

You must be kidding. If you replace packages from Packman with packages from openSUSE you will lose features missing in openSUSE and provided by Packman. If you did not need these features there was no reason to switch to Packman in the first place. If you need these features and they are missing now something on your system will stop working.

I naively assumed that the reason to use packages from Packman was to fix non-working multimedia when using packages from openSUSE. Of course if the reason to switch vendor is to have numerically higher package versions - you are right.

18

That’s fair; perhaps a response with less sarcasm would be a more kind approach, but you’re right to point out that there are differences beyond just a numeric difference between the packages.

In my case, for this particular package, it made no difference, as apparently I don’t end up using it often enough to notice, but others might notice the difference, and as such, staying with the Packman release would make more sense.

Fortunately, if someone does this the way I did it, the package is still in Packman, and they can switch back if they find that making the change breaks something in their setup.

19

So, by now the update went through without any issues.
In case of problems I also allow vendor change (never had a feature in some lib I missed), but this was the first time I encountered a file conflict so vendor change did nothing.

My takeaway: after orphan checking, I will check the build site.

21

Apparently Packman removed the libfaad2 from its lineup and the conflict vanished.
You should be asked to replace faad2 with the OSS version though:

LT-B:~ # zypper dup --no-recommends
Refreshing service 'NVIDIA'.
Refreshing service 'openSUSE'.
Loading repository data...
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...

Problem: 1: problem with the installed libfaad2-2.11.2-1699.2.pm.11.x86_64
 Solution 1: install libfaad2-2.11.2-2.1.x86_64 from vendor openSUSE
  replacing libfaad2-2.11.2-1699.2.pm.11.x86_64 from vendor http://packman.links2linux.de
 Solution 2: keep obsolete libfaad2-2.11.2-1699.2.pm.11.x86_64

Choose from above solutions by number or cancel [1/2/c/d/?] (c):

Choosing “Solution 1” makes everybody happy.

(Please remember to remove the lock to gstreamer-plugins-bad* if you added one)

1 Like
22

It’s not difficult, just read what Zypper Dup offers and select the solution that doesn’t change the supplier. If you’ve chosen that the Packman repo should manage the multimedia, just go with the solution that doesn’t change that choice.In the case above post Solution 2…very simple

23

This package was removed from packman. So solution 2 is wrong. It will leave you with an outdated, insecure package without future updates. Keeping obsolete versions is seldom a solution…

Packman regularly removes packages which are no longer hit by license issues. In this case it is absolutely necessary to switch the vendor back to openSUSE.

So as OrsoBruno already explained, solution 1 (switching the provider back to openSUSE) is the correct one.

1 Like
24

I didn’t know it had been abandoned by Packman, where you can see it … However, leaving aside the latter, the solution is not to change supplier, if you have Packman for multimedia you must not mix it with the Opensuse Repo

25

In the packman repo, in YaST Software versions tab, in Myrlyn version tab and with zypper se function. So virtually everywhere.

If a package is not avaolable on packman, you MUST install it from openSUSE repos. There is no mixing.

26

In fact if it is not in Packman there is no mix…it is obvious