(I submitted the request to them for FreeCAD).
It’s also 0.21.2, but built in November. Works fine. No dependency issues with KiCAD 7.0.10 installed on the same machine.
FreeCAD 0.21.2 appimage on Ubuntu 23.04
I noticed the KicadStepUp plugin was from last May and failed to detect any update available. So I uninstalled the plugin. Restarted and reinstalled and got the latest version.
On my system, after the installation of the FreeCAD appimage, the installation of plugins is blocked by missing permissions. Because I’m not that specialist to solve it, I looked for alternatives.
The solution from @mfraz74 looks nice, but I fear, the next updates will bring back the problem … Anyway, Thank you !
I found, the FreeCAD snap image works best for me. It allows plugins and does not update libocct 7.5 to 7.6, but uses it’s own private 7.6 version.
So I’ve got now KiCad 7.0.1 together with FreeCAD 21.2 and both are working fine.
My system:
Ubuntu Studio 22.04, KDE Plasma Version: 5.24.7, KDE Frameworks Version: 5.92.0, Qt Version: 5.15.3, Kernel Version: 6.5.0-15-lowlatency (64-bit)
Hello. I guess this is the third time as a user I have to deal with this conflict. This could be discouraging. And snap/appimages are not a solution I appreciate.
Looking at the libocct packages content, I see that most of the files are named using their major.minor numbers so the “Breaks” and “Replaces” in the control file are not really true and could be avoided, so that several version would be installable at the same time, then cleaned by apt autoremove when they become obsolete. Then the Kicad or Freecad application should link directly to the major.minor library file they require.
I have done some work on kv5 and kv6, but unfortunately only for linux up to ubuntu 20…
FC has a very reliable AppImage that use Conda to package everything.
With AppImage is much easier to handle external paths.
Edit:
And the nice part of AppImages is that you can have different releases at the same time.
I was not thinking about static link, and of course different packages that do not conflict can cohabit. (my system has different versions of gcc, gstreamer, libgtksourceview, liblua, libpcre, python, libsdl… at the same time).
My point is that in this case where “major.minor versions are never abi compatible” then the occt libraries themselves that depend to each other an the applications that use it should probably dynamically link to this specific major.minor version they require. This could prevent this dependency hell. This is not caused by the ecosystem but how we make it.