Yes, it's the correct place. Failure also noted here https://bugzilla.suse.com/show_bug.cgi?id=1220304#c2

Same bug.

I move the folder /usr/libexec/vitriofsd to temp folder and zypper installed this package fine.

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

The old rpm "can't replace a directory with a single file" deficiency.

Some more info here: bug #1220632

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

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

I ma running in the same issue as described in

https://bugzilla.suse.com/show_bug.cgi?id=1220598
https://bugzilla.suse.com/show_bug.cgi?id=1220632
https://bugzilla.suse.com/show_bug.cgi?id=1220592

The problem is that updating the package cannot be skipped if I deselect it in "Software Updates" popup in KDE. Even if I select a single unrelated package and deselect all others the process tries to update `virtiofsd` and fails.

This issue has been already reported here:

https://bugzilla.suse.com/show_bug.cgi?id=1186908
> Bug 1186908 - Software Updates applet: All available packages were updated even if I select only 1 of them

I believe the simplest workaround is to remove the virtiofsd package with 'zypper rm virtiofsd' and then install again with 'zypper in virtiofsd'. Removing the package and then doing a distro upgrade may also work (due to it being a qemu dependency). 'zypper in --force virtiofsd' does not work. This should all be safe since virtiofsd doesn't have any dependencies.

(In reply to Caleb Crane from comment #12)
> This should all be safe since virtiofsd doesn't have any dependencies.

That does not seem to be correct:

sudo zypper rm virtiofsd
Installierte Pakete werden gelesen...
Paketabhängigkeiten werden aufgelöst...

Die folgenden 8 Pakete werden GELÖSCHT:
  libguestfs libguestfs-appliance libguestfs-winsupport libguestfs-xfs perl-Sys-Guestfs qemu-tools virtiofsd vm-install

8 packages are connected to virtiofsd if you have installed the virtualization group in Yast. 
It was also my first impulse to simply uninstall, then reinstall, but stopped there since I'm not sure what exactly happens if I uninstall all the other 8packages with it.

Bug confirmed. 

The problem seems to be that the newer package includes the /usr/libexec/virtiofsd file while the previous one installed /usr/libexec/virtiofsd/virtiofsd. So zypper won't replace a directory with a file. But I suspect that putting the file in this wrong path can also creat problems.

The best seems to ignore and keep the old version (virtiofsd-1.10.1-2.1) as I got problems with my virtio network bridge after trying to force the newer versions (remove 1-2.1 without deps check then install 1-3.1). Some qemu program might be looking for the virtiofsd file in its previous path.

(In reply to Caleb Crane from comment #12)
> I believe the simplest workaround is to remove the virtiofsd package with
> 'zypper rm virtiofsd' and then install again with 'zypper in virtiofsd'.

This wanted to uninstall a whole bunch of qemu packages when I tried it.

It's far easier to download the new package, delete that directory and its contents, and install the downloaded package manually with 'rpm -Uhv' as described here:

  https://bugzilla.suse.com/show_bug.cgi?id=1220632#c4

This minimizes the disruption.

(In reply to Stefan Hundhammer from comment #15)
> It's far easier to download the new package, delete that directory and its
> contents, and install the downloaded package manually with 'rpm -Uhv' as
> described here:
> 
>   https://bugzilla.suse.com/show_bug.cgi?id=1220632#c4
> 
> This minimizes the disruption.

Okay, I guess my test scenarios were too contrived. Thanks for sharing this method.

A couple other things of note when fixing this manually:

 - Ending up with virtiofsd installed to '/usr/libexec/virtiofsd/virtiofsd' is flawed and should have never happened to begin with. This bug is the result of trying to undo that badness. The correct path is 'usr/libexec/virtiofsd' for TW.
 - Ensure the file '/usr/share/qemu/vhost-user/50-virtiofsd.json' points to the correct path for the virtiofsd binary. ('/usr/libexec/virtiofsd' is assumed)
 - Ensure the file '/etc/apparmor.d/usr.sbin.virtqemud' includes the correct path for virtiofsd ('/usr/libexec/virtiofsd' is assumed)

Given the above, things should be functional again.

%pre
if [ -d /usr/libexec/virtiofsd ] ; then
  rm -rf /usr/libexec/virtiofsd
fi

(In reply to Laurent Catinaud from comment #14)
> The best seems to ignore and keep the old version (virtiofsd-1.10.1-2.1) as
> I got problems with my virtio network bridge after trying to force the newer
> versions (remove 1-2.1 without deps check then install 1-3.1). Some qemu
> program might be looking for the virtiofsd file in its previous path.

If anything, programs will look for virtiofsd in /usr/libexec/. Moving it requires updating apparmor profiles, etc. No need to deviate from the rest of the world.

(In reply to Marcus Rückert from comment #17)
> %pre
> if [ -d /usr/libexec/virtiofsd ] ; then
>   rm -rf /usr/libexec/virtiofsd
> fi

+1 :-)

Created attachment 873140 [details]
Terminal error that shows up while trying distro-upgrade

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

My solution to allow other packages to be updated is to set the `viriofsd` package to "Protected -- Do not modify" in the YaST Package Manager until this is resolved.

(In reply to Jecho Jekov from comment #22)
> My solution to allow other packages to be updated is to set the `viriofsd`
> package to "Protected -- Do not modify" in the YaST Package Manager until
> this is resolved.

Same. I don't want to force install via removing the old package because it may be that some programs might expect virtiofsd in its old location. Imo this needs to be resolved by the developer/maintainer side.

Comment on attachment 873140 [details]
Terminal error that shows up while trying distro-upgrade

error: unpacking of archive failed on file /usr/libexec/virtiofsd;65e39691: 
cpio: File from package already exists as a directory in system
error: virtiofsd-1.10.1-3.1.x86_64: install failed
error: virtiofsd-1.10.1-2.1.x86_64: erase skipped
( 18/361) Installing: virtiofsd-1.10.1-3.1.x86_64 .......................[error]
Installation of virtiofsd-1.10.1-3.1.x86_64 failed:
Error: Subprocess failed. Error: RPM failed: Command exited with status 1.

(In reply to Nik Kai from comment #23)
> (In reply to Jecho Jekov from comment #22)
> > My solution to allow other packages to be updated is to set the `viriofsd`
> > package to "Protected -- Do not modify" in the YaST Package Manager until
> > this is resolved.
> 
> Same. I don't want to force install via removing the old package because it
> may be that some programs might expect virtiofsd in its old location. Imo
> this needs to be resolved by the developer/maintainer side.

Same. ""Protected -- Do not modify" in the YaST Package Manager until
it may be resolved."

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

This still pops up at numerous support channels. It's not fixed yet.

(In reply to Marcus Rückert from comment #17)
> %pre
> if [ -d /usr/libexec/virtiofsd ] ; then
>   rm -rf /usr/libexec/virtiofsd
> fi

Should have submitted this days ago:
https://build.opensuse.org/request/show/1155986

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

Benjamin's fix has been accepted in Factory. We can close this now.

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

(In reply to James Fehlig from comment #29)
> Benjamin's fix has been accepted in Factory. We can close this now.

virtioFSD has been changed to "update" and vendor "Factory" 4 TW some days ago.
Serveral zypper dups l8r no more loveltters from zypper about rc=1

works for me, thank you!!

For me, the problem still occurs, apparently because I've set ZYPP_SINGLE_RPMTRANS=1. Before anyone asks, I know it's tech preview; I like the feature, and I have it enabled as sort of a "beta tester" to find issues with it, like I just did.

While I can work around this easily, ZYPP_SINGLE_RPMTRANS has been around for 3 years. Quite a few people are waiting eagerly for it to leave tech preview state, and even become the default, on openSUSE. We should stop pushing workarounds for issues like this that are only effective if this variable is not set.

I assume that replacing %pre with %pretrans in Ben's fix would do the trick.

(In reply to Martin Wilck from comment #32)
> For me, the problem still occurs, apparently because I've set
> ZYPP_SINGLE_RPMTRANS=1. Before anyone asks, I know it's tech preview; I like
> the feature, and I have it enabled as sort of a "beta tester" to find issues
> with it, like I just did.
Do you have a set of preferred references for this feature? I personally don't keep up to date with experimental zypper features, but I'm willing to explore the merits of this feature.

> I assume that replacing %pre with %pretrans in Ben's fix would do the trick.
My observation has been that many packages are moving away from %pretrans to %pre so I'm a little wary of going that direction without more research.

as replied in the imagemagick bug with the same issue

- %pretrans is even more dangerous than the cleanup in %pre
- %pretrans does not support shell scripts it needs to be implemented in lua

in general the recommendation is do _not_ replace directories with file/symlink or vice versa.

(In reply to Caleb Crane from comment #33)

> Do you have a set of preferred references for this feature? I personally
> don't keep up to date with experimental zypper features, but I'm willing to
> explore the merits of this feature.

I don't remember everything off the top of my head. I recall that the upgrade is supposed to be faster, because rpm doesn't have to be called for every package in turn, and because %pretrans and and %posttrans scripts really only run once; this is a huge improvement e.g. for packages that require rebuilding the initrd. If you have 10 packages that want to rebuild the initrd in the transaction, you will rebuild it 10x with the traditional method, which causes time-consuming pointless work for the CPU.

Also, rpm itself is aware of the entire transaction, which simplifies matters and allows some additional optimizations, IIRC. I've seen this feature mentioned as possible solution to some problems in various bugs, but I don't recall them all.

Michael should be able to fill in more detail, also about the question why this has still not left tech preview state.

(In reply to Marcus Rückert from comment #34)
> as replied in the imagemagick bug with the same issue
> 
> - %pretrans is even more dangerous than the cleanup in %pre
> - %pretrans does not support shell scripts it needs to be implemented in lua

You just said "its kinda dangerous", without providing much background. I can see that %pretrans might be tricky in particular for initial installation, when there's basically nothing we can rely on, but this is just a vague perception.
Adding some LUA code to unlink a file under /etc/alternatives might actually be possible.

> in general the recommendation is do _not_ replace directories with file/symlink or vice versa.

Yes. But obviously, this recommendation hasn't been followed well lately, and QA hasn't found the issues that this caused. The way this has played out, I have little confidence that such errors will be effectively avoided in the future.

Am I understanding correctly that you're basically saying "there will never be a fix for current and future directory <-> file replacement bugs that work with ZYPP_SINGLE_RPMTRANS=1"? Does this mean this feature is officially dead?

well there is a simple way to find that during the build by comparing the old build (which is available) with the new build and if we find a type collusion then always hard fail the build.

so that would require a new rpmlint or post-build-check test to be implemented?

yes

I guess if, as you say, the previous package is available on OBS, it would be sufficient to try install it and attempt an update.

related blog post about this and the dangers that come with it https://nordisch.org/posts/the-short-answer-is-dont/

the blog post has a bug and is being reworked.