Bug 1000003

I hit the issue once while developing the branding package but thought it was just me having screwed around with those files too much. Now openQA spotted it as well: https://openqa.opensuse.org/tests/266737#step/zdup/96

Why do you say that no symlinks are involved? The plasma5-workspace-branding-openSUSE-13.2-21.1 package from Leap 42.1 contains:

lrwxrwxrwx    1 root    root                       48 Oct 28 05:36 /usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components -> ../../org.kde.breeze.desktop/contents/components

Thus the conflict seems valid to me.

(In reply to Michael Schröder from comment #2)
> Why do you say that no symlinks are involved? The
> plasma5-workspace-branding-openSUSE-13.2-21.1 package from Leap 42.1
> contains:
> 
> lrwxrwxrwx    1 root    root                       48 Oct 28 05:36
> /usr/share/plasma/look-and-feel/org.openSUSE.desktop/contents/components ->
> ../../org.kde.breeze.desktop/contents/components
> 
> Thus the conflict seems valid to me.

That is the old version of the package that is replaced by a new one, that does not use a symlink any more.

Why would that matter? The openQA test is trying to upgrade from 42.1 to 42.2, so the symlink exists when zypper is run.

Note that you simply *cannot* replace a directory with a symlink and vice versa with a package update.

(In reply to Michael Schröder from comment #4)
> Why would that matter? The openQA test is trying to upgrade from 42.1 to
> 42.2, so the symlink exists when zypper is run.
> 
> Note that you simply *cannot* replace a directory with a symlink and vice
> versa with a package update.

That's bad... What has to be done to accomplish this? The symlink _has_ to be replaced by a real directory.

Sorry, not possible. rpm-wise you could do some magic with a pre-trans script written in lua, but the file conflict check is done before any transaction is run.

CC Michael Andres for advice.

The issue was introduced with an online update of 42.1, right? So could we fix the issue in 42.1 by undoing the symlink there? Since the file content is identical in 42.1 there should actually be no file conflict.

(In reply to Ludwig Nussel from comment #7)
> The issue was introduced with an online update of 42.1, right? So could we
> fix the issue in 42.1 by undoing the symlink there? Since the file content
> is identical in 42.1 there should actually be no file conflict.

Tumbleweed has the issue as well.

(In reply to Michael Schröder from comment #6)
> Sorry, not possible. rpm-wise you could do some magic with a pre-trans
> script written in lua, but the file conflict check is done before any
> transaction is run.
> 
> CC Michael Andres for advice.

Does rpm execute the pre-trans before checking for file conflicts? Anyway, we don't have any execution hook before the fileconflict check in libzypp.

*** Bug 1000001 has been marked as a duplicate of this bug. ***

(Yes, IIRC pretrans is run before the file conflict check. Which is highly dubious as well, as your system may be in a weird state after the pretrans scripts are run. But redhat did it that way because of their /usr move.)

*** Bug 1000002 has been marked as a duplicate of this bug. ***

The solution we came up with was:
- Rename the components directory to components-real during build
- Add a symlink components -> components-real

That way only the symlink target changes instead of the inode type.
However, this would break when updating the broken beta package to this one,
as the directory components would change _back_ to be a symlink again.
So a %pre script that does it for rpm got added and now everything should be fine...

*** Bug 1001667 has been marked as a duplicate of this bug. ***

Author: mksmith
Date: 2018-09-05 16:06:24 -0600 (Wed, 05 Sep 2018)

New Revision: 188859

Log: [Bug 1000003] - A sample registry file to help the driver load properly, to be used AFTER installing the driver.

Added:
   branches/trunk.Migrate.MM/FileSystemMonitorDriver/driver/minispy.reg