Update file conflict - safe to ignore?

Hello again!

On one install (TW KDE, only special iirc is printing repo) I get from time to time on updating since spring (?) a warning about a file conflict

https://paste.opensuse.org/b6355e84

I usually ignored it in the past, is it safe? Or any way to avoid this in the future?

Generally speaking, no, it is not safe.

The same file is installed by two (or more) packages, but it can of course only exist once on disk.
So one package overwrites the file from the other package.

In this particular case, it shouldn’t cause any real problems though.
It only affects kdesu, the KDE4 version from kdebase4-runtime won’t be available (as it is overwritten by kde-cli-tools5), but they are equivalent (just using different libs).

Or any way to avoid this in the future?

Uninstall kdebase4-runtime that has been dropped from Tumbleweed a year ago.

That said, this conflict shouldn’t be there in the first place, because the packages used update-alternatives to be able to choose between the KDE4 and KF5 versions of kdesu.

What repos are you using? Where did you install kdebase4-runtime from?

zypper lr -d
rpm -qi kdebase4-runtime

Hi and thanks!

I have

zypper lr -d
# | Alias                               | Name                        | Enabled | GPG Check | Refresh | Priority | Type   | URI                                                                     | Service
--+-------------------------------------+-----------------------------+---------+-----------+---------+----------+--------+-------------------------------------------------------------------------+--------
1 | http-download.opensuse.org-3b546aac | Printing                    | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/repositories/Printing/openSUSE_Tumbleweed/ | 
2 | http-download.opensuse.org-e101edc7 | utilities                   | Yes     | (r ) Yes  | Yes     |   94     | rpm-md | http://download.opensuse.org/repositories/utilities/openSUSE_Factory/   | 
3 | openSUSE_Tumbleweed                 | Mozilla                     | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | https://download.opensuse.org/repositories/mozilla/openSUSE_Tumbleweed  | 
4 | repo-non-oss                        | openSUSE-Tumbleweed-Non-Oss | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/tumbleweed/repo/non-oss/                   | 
5 | repo-oss                            | openSUSE-Tumbleweed-Oss     | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/tumbleweed/repo/oss/                       | 
6 | repo-update                         | openSUSE-Tumbleweed-Update  | Yes     | (r ) Yes  | Yes     |   99     | rpm-md | http://download.opensuse.org/update/tumbleweed/

and

rpm -qi kdebase4-runtime
Name        : kdebase4-runtime
Version     : 17.08.3
Release     : 7.1
Architecture: x86_64
Install Date: Sa 19 Okt 2019 18:24:35 CEST
Group       : System/GUI/KDE
Size        : 16211588
License     : GPL-2.0-or-later
Signature   : RSA/SHA256, Mo 14 Okt 2019 15:33:06 CEST, Key ID b88b2fd43dbdc284
Source RPM  : kdebase4-runtime-17.08.3-7.1.src.rpm
Build Date  : Mo 14 Okt 2019 15:31:48 CEST
Build Host  : cloud117
Packager    : https://bugs.opensuse.org
Vendor      : openSUSE
URL         : http://www.kde.org/
Summary     : The KDE Runtime Components
Description :
This package contains all run-time dependencies of KDE applications.
Distribution: openSUSE Tumbleweed

The second one looks really strange to me… How to check which application drew this in as a dependency? oO

Some KDE4 application.
But all KDE4 remainders (and Qt4 as well) have been dropped from Tumbleweed meanwhile (in Autumn 2019).

Btw, regarding the file conflict:
It’s because two months ago there was a change to the build service macros that handle symlinks when creating the packages, and zypper gets confused by this change, it doesn’t realize that the symlinks are still the same.
I.e. it’s actually a false positive in this case.

A rebuild of kdebase4-runtime would “fix” that, but as kdebase4-runtime doesn’t exist in Tumbleweed anymore, it wasn’t (and won’t be) rebuilt of course…

See e.g. 1171640 – File Conflict When Updating sddm for more information.

I uninstalled the kde4…, it complained that knutclient was depending. Why should I install a NUT client on a notebook? Strange…

I uninstalled the knutclient and now conflict is gone!

Many thanks for support…

PS: Really sure you linked the right bigzilla thread?

No idea.
It certainly isn’t installed by default though, I even think it actually never was part of the distribution at all (it wasn’t in any Leap nor in openSUSE 13.2 or earlier, I’m not sure about Tumbleweed but rather not as well).

PS: Really sure you linked the right bigzilla thread?

Yes.
It may have been specifically filed about sddm (conflict with lightdm and xdm), but the problem was a general one that would affect all packages using update-alternatives in particular.

zypper doesn’t warn about the “conflict” if two symlinks are identical, because it doesn’t matter then that they are installed by more than one package, of course.

The problem here is that the symlinks in the packages changed (from being absolute to being relative) two months ago.
From the bug report:

235s] -/usr/lib/X11/displaymanagers/default-displaymanager 0 (none) 120777 root root 0 4294967295 /etc/alternatives/default-displaymanager
235s] +/usr/lib/X11/displaymanagers/default-displaymanager 0 (none) 120777 root root 0 4294967295 …/…/…/…/etc/alternatives/default-displaymanager

But that change only happens when the package is rebuilt with the new macros.

So kdebase4-runtime still has /usr/bin/kdesu as an absolute symlink (pointing to /etc/alternatives/kdesu), while kde-cli-tools5 already has a relative one (pointing to …/…/…/…/etc/alternatives/kdesu).
zypper thinks they are different, and warns about the “conflict”.

Or, to quote from the bug report:

The change to force relative symlinks in brp-checks-suse now results that the package is no longer coinstallable with packages built before the switch to relative symlinks. Either this has to be reverted or all affected packages rebuilt.