error: Checkout unixODBC-2.3.7-5.fc31.i686: Hardlinking #1937
Comments
|
rpm-ostree itself does support multilib, so I suspect there's something going wrong in that logic. |
|
Thanks for the bug label! I'll follow up with the winepak and report back if needed! |
|
Hello! Not sure if it makes sense to add here or to open another but, but there is the same problem with SilverBlue 32, w/o additional repostories. After a 'rpm-ostree install wine' the transaction fails with: |
|
On fedora Silverblue 33, installing 'libstdc++.i686' fails with error: |
|
$ rpm-ostree --version
|
|
I can now install libstdc++.i686, but, still, cannot install wine. |
|
Fedora Silverblue 33 and this error still persists |
|
Also present on Silverblue 34 Found this while trying to layer gamehub, which pulls Wine |
|
Before this entirely leaves my brain: I looked at this some time back and started hacking on a patch, but didn't push through. The base issue IIRC is that |
|
It has been working for me in SB32 and SB33, but it's now back in SB34. Is there a workaround (besides not using wine) available for this issue?
|
|
Same for me when installing Lutris on SB34:
|
|
Most prominently (I presume) this affects Lutris since it introduced a weak-dependency to wine-core (32-bit). A workaround is to grab the latest version which came without the weak-dependency from Koji, which is: 0.5.8.3-4 As Lutris is steadily developed this workaround will get less and less feasible. @cgwalters Is this an issue that needs further discussion/concept work or is it ready to be implemented/getting fixed? EDIT: Two options come to mind: Fixing the underlying Hardlinking issue or allow skipping weak-dependencies either manually or as an error handler for when the Hardlinking error is thrown. Skipping weak-dependecies will introduce further issues as the 32-bit runners of Lutris will fail if wine-core (32-bit) is not present, as that was the original reason the weak dep was introduced for the package. |
|
The workaround is no longer applicable for SB35. The fc34 package is incompatible as it has a hard requirement to python3.9 and the .fc35 packages start after the introduction of the weak-dep to wine-core (32-bit): https://koji.fedoraproject.org/koji/search?terms=lutris*.fc35&type=build&match=glob |
Before, we were only comparing rpm file coloring between layered packages and base packages. But we also need to compare layered packages among themselves. A concrete example is `unixODBC` which isn't in e.g. Fedora Silverblue, but which some packages pull in both the i686 and x86_64 versions. In that case, we need to skip the checkout of files in the i686 version which are also in the x86_64 one. Closes: coreos#1937
|
Fix for this in #3161. |
Before, we were only comparing rpm file coloring between layered packages and base packages. But we also need to compare layered packages among themselves. A concrete example is `unixODBC` which isn't in e.g. Fedora Silverblue, but which some packages pull in both the i686 and x86_64 versions. In that case, we need to skip the checkout of files in the i686 version which are also in the x86_64 one. Closes: coreos#1937
Before, we were only comparing rpm file coloring between layered packages and base packages. But we also need to compare layered packages among themselves. A concrete example is `unixODBC` which isn't in e.g. Fedora Silverblue, but which some packages pull in both the i686 and x86_64 versions. In that case, we need to skip the checkout of files in the i686 version which are also in the x86_64 one. Closes: coreos#1937
Before, we were only comparing rpm file coloring between layered packages and base packages. But we also need to compare layered packages among themselves. A concrete example is `unixODBC` which isn't in e.g. Fedora Silverblue, but which some packages pull in both the i686 and x86_64 versions. In that case, we need to skip the checkout of files in the i686 version which are also in the x86_64 one. Closes: #1937
|
This problem has resurfaced in SB40. |
Host system details
Expected vs actual behavior
Expected:
Steps to reproduce it
Refer to section "Host system details"
Would you like to work on the issue?
I am fully aware of the issues for Fedora Silverblue not supporting 32bit libraries going forward, but this is serious roadblock for users who wish to use Wine to play games such as Battlefield 3-5 via Origin on Linux. Unsure if WineHQ will attempt to flatpak the winehq-staging package any time soon...
I would love to help contribute but do not know where to start or how... feel free to contact me directly for further information.
The text was updated successfully, but these errors were encountered: