haxe
haxe copied to clipboard
HaxeFoundation
Package conflict between haxe 4.2.4 and nekovm 2.3.0 on Fedora 36
Seems the problem from #9950 is still happening. Looks like there is a conflict between the haxe package and the nekovm package, but the nekovm package is a dependency of the haxe package.
Seeing as nekovm is deprecated, maybe the better solution is to not make nekovm a dependency?
Console Output:
sudo dnf install haxe
Last metadata expiration check: 3:53:17 ago on Sun 17 Apr 2022 08:17:38 PM PDT.
Dependencies resolved.
================================================================================================================================================================================================================================================
Package Architecture Version Repository Size
================================================================================================================================================================================================================================================
Installing:
haxe x86_64 4.2.4-3.fc36 fedora 5.5 M
Installing dependencies:
haxe-stdlib noarch 4.2.4-3.fc36 fedora 1.0 M
mbedtls x86_64 2.28.0-2.fc36 fedora 391 k
nekovm x86_64 2.3.0-9.fc36 fedora 416 k
Transaction Summary
================================================================================================================================================================================================================================================
Install 4 Packages
Total size: 7.4 M
Total download size: 807 k
Installed size: 29 M
Is this ok [y/N]: Y
Downloading Packages:
[SKIPPED] haxe-4.2.4-3.fc36.x86_64.rpm: Already downloaded
[SKIPPED] haxe-stdlib-4.2.4-3.fc36.noarch.rpm: Already downloaded
(3/4): mbedtls-2.28.0-2.fc36.x86_64.rpm 602 kB/s | 391 kB 00:00
(4/4): nekovm-2.3.0-9.fc36.x86_64.rpm 623 kB/s | 416 kB 00:00
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 626 kB/s | 807 kB 00:01
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction test error:
file /usr/lib/.build-id/48/bc9d5a99376793d19c2621cadd6c59cd497761 conflicts between attempted installs of haxe-4.2.4-3.fc36.x86_64 and nekovm-2.3.0-9.fc36.x86_64
Same issue with me, I just want to build native versions of Haxe software on Fedora (which is usually just pretty easy)
Same issue with me, I just want to build native versions of Haxe software on Fedora (which is usually just pretty easy)
I was able to install the dependencies separately from haxe. It seems like only haxe is conflicting.
This problem is still occuring a year later.
file /usr/lib/.build-id/b8/acf4f8271b78cd6dca636cb5b877c5c64f47f4 conflicts between attempted installs of haxe-4.2.5-5.fc38.x86_64 and nekovm-2.3.0-11.fc38.x86_64
Does it work with
4.3.1-1.fc39?
Negative.
package haxe-4.2.5-5.fc38.x86_64 requires haxe-stdlib = 4.2.5
I've installed haxe-stdlib-4.3.1-1.fc39.noarch but it provides only a dependency, not any executable.
Afterwards I tried to install the F38 provided 'haxe' with this:
sudo dnf install haxe --exclude=haxe-stdlib
Why did you do that?
You should be using both haxe and haxe-stdlib with the same version (so 4.3.1 here)
Tried that now:
- nothing provides libm.so.6(GLIBC_2.38)(64bit) needed by haxe-4.3.1-1.fc39.x86_64
- nothing provides glibc >= 2.37.9000-8 needed by haxe-4.3.1-1.fc39.x86_64
I have glibc-2.37-4.fc38.src.rpm on F38.
Have you guys considered using COPR to build the RPMs, even if to just validate the build using a more Fedora focused build system?ight help catch errors like this.
COPR is like PPAs or the Arch AUR for Fedora. https://copr.fedorainfracloud.org/
I am currently on vacation but I can look into your build setup when I get back and see if I can improve it for Fedora (not COPR, but whatever is used now to build the RPMs) to fix these issues. Since I use Fedora and am a DevOps engineer.
The .build-id conflict has been a long standing issue (reported in the fedora devel mailing sometime ago).
Before the root cause is fixed, right now I just "solve" it by rebuilding the neko package everytime.
The nothing provides libm.so.6(GLIBC_2.38)(64bit)/glibc >= 2.37.9000-8 error happened because the f39 package is used on a f38 system.
I've just rebuilt the f38 neko package and submitted an update: https://bodhi.fedoraproject.org/updates/FEDORA-2023-9f87d63df2 If you want f38 haxe 4.3.1, there is https://bodhi.fedoraproject.org/updates/FEDORA-2023-2a214c01e9
