F39 libpng hard link error

[terminal-cs]

This issue tracker is intended only for Silverblue specific issues. We would like to ask you to try to reproduce the issue on a relevant Fedora Workstation release. If you will be able to reproduce there, then please report it in Red Hat Bugzilla (see How to file a bug) or in upstream (preferred for GNOME projects) and not in this issue tracker.

Describe the bug I am currently attempting to remove java from my system as i no longer need it, but a hard link error occurs and i am unable to remove it. This also seems to occur when removing other packages.

To Reproduce Please describe the steps needed to reproduce the bug:

1. Attempt to remove a package
2. see Checkout libpng-2:1.6.40-3.fc40.i686: Hardlinking 39/7c89a98231c3b481059edb3d1af431d21ef5c538d1b18adb004aaeb88bc02f.file to LICENSE: File exists

Expected behavior The packages should be removed like normal

Screenshots If applicable, add screenshots to help explain your problem.

OS version:

State: idle
BootedDeployment:
● fedora:fedora/39/x86_64/kinoite
                  Version: 39.20240301.0 (2024-03-01T00:42:46Z)
               BaseCommit: 18ac8822755b1bc721c2498109125f140c94ca5db0e88495a673425018479f85
             GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C
          LayeredPackages: gstreamer1-plugin-openh264 java mozilla-openh264 timeshift wine

Additional context Add any other context about the problem here.

[travier]

Can you try resetting your overrides and then re-adding only what you need?

$ rpm-ostree override reset --all
$ rpm-ostree install ...

[terminal-cs]

Can you try resetting your overrides and then re-adding only what you need?

$ rpm-ostree override reset --all
$ rpm-ostree install ...

Nope, causes the same issue.

[chrisawi]

Checkout [...] Hardlinking [...] to LICENSE: File exists

This happens when two packages install the same file and those files aren't identical, i.e. they're in conflict.

libpng-2:1.6.40-3.fc40.i686

Why is it layering an F40 package on F39? I don't know how that would be possible unless you've hardcoded that version in place of $releasever in /etc/yum.repos.d/.

Anyway, that's the source of the conflict. F39's libpng.x86_64 in the base image has a different LICENSE file (the copyright year changed).

[terminal-cs]

Checkout [...] Hardlinking [...] to LICENSE: File exists

This happens when two packages install the same file and those files aren't identical, i.e. they're in conflict.

libpng-2:1.6.40-3.fc40.i686

Why is it layering an F40 package on F39? I don't know how that would be possible unless you've hardcoded that version in place of $releasever in /etc/yum.repos.d/.

Anyway, that's the source of the conflict. F39's libpng.x86_64 in the base image has a different LICENSE file (the copyright year changed).

How can i fix this? I haven't done anything too crazy with the system. I've only tried testing F40 on the second boot partition while my main os (F39) was pinned, and later rolled back because one thing was missing that i needed. Should i completly reset the second partition somehow?

Also thanks for the help, the community is great.

[terminal-cs]

Update: running rpm-ostree upgrade seems to fix it. Probably overwrites the other partition and fixes the issue. I'll leave the issue open incase anybody has something to say, but it can be closed whenever because my issue is solved.

[chrisawi]

I've only tried testing F40 on the second boot partition while my main os (F39) was pinned, and later rolled back

Ah, I see the issue template only asks for rpm-ostree status -b. Full rpm-ostree status may have made this more clear.

If you had booted the rollback deployment using the bootloader menu, the F40 deployment would have remained the default deployment, and rpm-ostree transactions would apply to it instead of the booted F39. You'd either need to rpm-ostree rollback to swap the order, or rebase to a new F39 deployment.

To be clear, deployment aren't partitions; ostree isn't an A-B partition system. If you pin deployments, you can have as many as your disk can hold.

Also, I generally recommend avoiding layering i686 packages if possible. It introduces many opportunities for dependency resolution failures and for conflicts like this. Wine is available on Flathub both by itself and inside frontends like Bottles. It should also be possible to install it inside a toolbox container.