In the packaging guidelines we call out the problematic upgrades for replacing a directory with a non-directory, or replacing a symlink with a directory.
We don't mention replacing a regular file with a directory though. Empirically that appears to be a broken scenario too.
# ls -al /usr/lib64/gimp/3.0/plug-ins/gmic_gimp_qt -rwxr-xr-x. 1 root root 10443848 Aug 29 2024 /usr/lib64/gimp/3.0/plug-ins/gmic_gimp_qt
# dnf update --enablerepo=updates-testing gmic-gimp ...snip... [5/8] Upgrading gmic-gimp-0:3.5.2-4.fc41.x86_64
[RPM] failed to open dir gmic_gimp_qt of /usr/lib64/gimp/3.0/plug-ins/gmic_gimp_qt/: cpio: mkdir failed - File exists [RPM] unpacking of archive failed on file /usr/lib64/gimp/3.0/plug-ins/gmic_gimp_qt/gmic_gimp_qt;67ceae1e: cpio: mkdir failed - Directory not empty Unpack error: gmic-gimp-0:3.5.2-4.fc41.x86_64
Did something change in cpio, or has it always been broken for regular file to directory replacement too, and our docs were thus always incomplete ?
With regards, Daniel
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacem...
Dne 10. 03. 25 v 10:22 dop. Daniel P. Berrangé napsal(a):
Did something change in cpio, or has it always been broken for regular file to directory replacement too, and our docs were thus always incomplete ?
It was always this way.
The same for replacing a file with symlink. Or vice versa.
On Mon, Mar 10, 2025 at 10:26:12AM +0100, Miroslav Suchý wrote:
Dne 10. 03. 25 v 10:22 dop. Daniel P. Berrangé napsal(a):
Did something change in cpio, or has it always been broken for regular file to directory replacement too, and our docs were thus always incomplete ?
It was always this way.
The same for replacing a file with symlink. Or vice versa.
Ok, so the packaging docs should say that /any/ change in file type between dir, regular & symlink needs special handling with lua scriptlets. I'll see about submitting a docs patch.
With regards, Daniel
On 3/10/25 11:30 AM, Daniel P. Berrangé wrote:
On Mon, Mar 10, 2025 at 10:26:12AM +0100, Miroslav Suchý wrote:
Dne 10. 03. 25 v 10:22 dop. Daniel P. Berrangé napsal(a):
Did something change in cpio, or has it always been broken for regular file to directory replacement too, and our docs were thus always incomplete ?
It was always this way.
The same for replacing a file with symlink. Or vice versa.
Ok, so the packaging docs should say that /any/ change in file type between dir, regular & symlink needs special handling with lua scriptlets. I'll see about submitting a docs patch.
Basically, if there's a directory involved, it can't be replaced on way or the other. A symlink to a directory is treated as a directory, so that counts. Otherwise file types can change.
Looking at this thread, rpm isn't detecting all the cases as conflicts as it should.
- Panu -
On 2025-03-10 2:30 AM, Daniel P. Berrangé wrote:
On Mon, Mar 10, 2025 at 10:26:12AM +0100, Miroslav Suchý wrote:
Dne 10. 03. 25 v 10:22 dop. Daniel P. Berrangé napsal(a):
Did something change in cpio, or has it always been broken for regular file to directory replacement too, and our docs were thus always incomplete ?
It was always this way.
The same for replacing a file with symlink. Or vice versa.
Ok, so the packaging docs should say that /any/ change in file type between dir, regular & symlink needs special handling with lua scriptlets. I'll see about submitting a docs patch.
This topic has come up a few times this year, and it seems like working around RPM's limitations with Lua scripts doesn't work in some situations, including system upgrades:
https://bugzilla.redhat.com/show_bug.cgi?id=2406164
I'm seeing a fair number of users report that this issue prevents them from updating to Fedora 43, and many of them are waiting, expecting the packager to resolve the problem.
I would suggest that Fedora's policies should express a very strong preference for avoiding Lua scripts by simply renaming the directory that contains contents that need to change.
That is, if "/usr/lib64/<app>/foo" is going to change from a directory to something else (or visa versa), then the package should simply use a different prefix, such as "/usr/lib64/<app>2"
I think this approach is similar to using "epoch" to resolve a version ordering issue.
Such a change could be reverted after two Fedora releases.
On Tue, Dec 9, 2025 at 5:02 AM Gordon Messmer gordon.messmer@gmail.com wrote:
On 2025-03-10 2:30 AM, Daniel P. Berrangé wrote:
On Mon, Mar 10, 2025 at 10:26:12AM +0100, Miroslav Suchý wrote:
Dne 10. 03. 25 v 10:22 dop. Daniel P. Berrangé napsal(a):
Did something change in cpio, or has it always been broken for regular file to directory replacement too, and our docs were thus always incomplete ?
It was always this way.
The same for replacing a file with symlink. Or vice versa.
Ok, so the packaging docs should say that /any/ change in file type between dir, regular & symlink needs special handling with lua scriptlets. I'll see about submitting a docs patch.
This topic has come up a few times this year, and it seems like working around RPM's limitations with Lua scripts doesn't work in some situations, including system upgrades:
https://bugzilla.redhat.com/show_bug.cgi?id=2406164
I'm seeing a fair number of users report that this issue prevents them from updating to Fedora 43, and many of them are waiting, expecting the packager to resolve the problem.
I would suggest that Fedora's policies should express a very strong preference for avoiding Lua scripts by simply renaming the directory that contains contents that need to change.
That is, if "/usr/lib64/<app>/foo" is going to change from a directory to something else (or visa versa), then the package should simply use a different prefix, such as "/usr/lib64/<app>2"
I think this approach is similar to using "epoch" to resolve a version ordering issue.
Such a change could be reverted after two Fedora releases.
I don't think that's going to always be feasible, since that may require patching code. It would be nice if we finally had some kind of rpm native solution so that transaction checks don't fail in this case.
I vaguely recall that either Michael Schroeder or Michal Domonkos said they had an idea on how to solve this, I don't know if either of them made an attempt at it. Maybe either of them could chime in with some answer here?
On 2025-12-09 2:30 AM, Neal Gompa wrote:
I don't think that's going to always be feasible, since that may require patching code.
It's possible that there are components where this will not be straightforward, but I think the *common* case is that directory prefixes can be set at build time, and patching is not required.
Wine is actually unusual in that (AFAICT) $(libdir)/wine is hard coded in a bunch of places and not configurable at build time. But that doesn't seem to be a problem, because we can just set $(libdir) to a new prefix:
https://src.fedoraproject.org/rpms/wine/pull-request/28#request_diff
I have verified that this builds.
I have not verified the upgrade, but since nothing will change from a directory to a symlink, the problem should no longer manifest.
I have verified that I am able to run "notepad.exe" included with Wine. I don't have any other Windows software to test.
This change could be applied to the F43 package and kept for two releases, and then reverted, or a similar change could be applied in F42, so that an up-to-date F42 system would not have path conflicts with F43.
On 12/10/25 1:46 AM, Gordon Messmer wrote:
On 2025-12-09 2:30 AM, Neal Gompa wrote:
I don't think that's going to always be feasible, since that may require patching code.
It's possible that there are components where this will not be straightforward, but I think the *common* case is that directory prefixes can be set at build time, and patching is not required.
Exactly. If it's *possible* to handle a case by renaming a directory, then that should always be the primary resolution. %pretrans hacks should always be the last gasp method because it's so fundamentally and terribly broken and dangerous, and unfixable.
Wine is actually unusual in that (AFAICT) $(libdir)/wine is hard coded in a bunch of places and not configurable at build time. But that doesn't seem to be a problem, because we can just set $(libdir) to a new prefix:
https://src.fedoraproject.org/rpms/wine/pull-request/28#request_diff
I have verified that this builds.
I have not verified the upgrade, but since nothing will change from a directory to a symlink, the problem should no longer manifest.
I have verified that I am able to run "notepad.exe" included with Wine. I don't have any other Windows software to test.
This change could be applied to the F43 package and kept for two releases, and then reverted, or a similar change could be applied in F42, so that an up-to-date F42 system would not have path conflicts with F43.
Thanks for looking into this solution!
- Panu -
On Tue, Dec 09, 2025 at 05:30:09AM -0500, Neal Gompa wrote:
I vaguely recall that either Michael Schroeder or Michal Domonkos said they had an idea on how to solve this, I don't know if either of them made an attempt at it. Maybe either of them could chime in with some answer here?
Assuming that the above issue is the same as these two:
https://bugzilla.redhat.com/show_bug.cgi?id=1936422 https://github.com/rpm-software-management/rpm/issues/1458
Then yep, I did make an attempt at improving the conflict detection heuristic in RPM (that would allow the transaction test, done by DNF, to pass) a while ago:
https://github.com/rpm-software-management/rpm/pull/1684
Unfortunately, there were some (implementation) issues with that approach which I didn't dedicate more time to and abandoned the PR in the end. If I remember correctly, those issues weren't necessarily deal-breakers but they required some more thought. Maybe we could revive it at some point as a sort of bandaid, but it really calls for a proper, supported way of doing these symlink/dir replacements in RPM.
-
Daniel P. Berrangé -
Gordon Messmer -
Michal Domonkos -
Miroslav Suchý -
Neal Gompa -
Panu Matilainen