There were some discussion about using appimage and why the krita version in repository differ. I am moving all the discussion to this topic please continue it here.
1 Like
why is the onus on the users to know to use the package of krita instead of the krita team contacting the Debian and Arch maintainers to make sure that the packages are being built correctly?
And the Snap package builders and the Flatpack builders and the maintainers of any other Linux distribution that doesn’t inherit repos from Debian or Arch.
It would be a lot to add to an already very full plate.
Additionally to @AhabGreybeard:
Why don’t read the maintainers of those badly built versions the build instructions?
What for are build instructions meant than to obey them?
Why do they believe they can leave out the dependencies patched by the Krita developers, needed only for one reason, to make Krita work? For instance, the patched Qt-libs?
G’MIC was another example of unread build instructions.
After the release of Krita 5 many repo versions of Krita missed integrating G’MIC. And because the interface to link to G’MIC was removed, all these versions had no way to access G’MIC.
Why? Because of unread build instructions.
Why the heck software gets updates? To change nothing?
When a software gets an update/upgrade, especially the “big ones”, if the number changes before or after the first point, then there are always many big changes to a software.
But then not reading the build instructions, passing the source code unchecked into the compiler and relying on an “it’ll be fine” attitude is grossly negligent. And yet it seems to be common practice with quite a few distributions to act in this way and not to act at all.
Although the forgotten G’MIC, which is part of Krita for about 2 years now, is said to be known to most maintainers in between.
There are (apparently very few) repos that are built according to the build instructions, and they work because the maintainers of these repos were obviously not too lazy to read and follow the build instructions!
Michelist
1 Like
Without going in to heated debate or antogonising the packagers I can say why this happens. There are two issues
Issue about patches -
- Krita team patches Qt the main toolkit required for not just krita but also many other software. Without these patches there will be glitches and crashes.
- These patches need to be merged in main Qt repository only then Distributions can use them since making any changes to Qt will also affect other packages like for example telegram or nextcloud or qbittorrent which use Qt. Some of these changes may break other packages. These patches first need to acknowledged and merged by upstream.
- So now both krita team and Distribution packagers do not have the control until the patches are upstream and you get broken krita in repositories.
Issue of newer dependencies -
Some distribution carry older dependencies sometimes some library is built without any enhancement or some other thing that krita needs due to policy of the distribution. For example ffmpeg in arch repository may be different from ffmpeg in fedora due to legal reason and it may be different in debian due to debians non-free vs free policy.
Some times krita might need a very recent dependency to work which might not even be in any distribution.
All this leads to issues that are out of control for both krita developers and the packagers.
Using appimage and flatpak also gives krita developers single source or truth or a single package to provide support for they know what combinations of library is used in appimage so they can provide some amount of support for it. it eases their workload.
5 Likes
It is also on Snap although it is the previous version I think they will update it soon.
I am against all those containers like snaps, dockers, vms and what not. I get what they provide, but to me simplicity is more valuable and I am willing to give up certain things to get it. In this case some brushes.
1 Like
Well Snap and flatpak are not like docker and in fact the furthest away from even the first two is appimage, appimage is a portable that is extracted temporarily, if you don’t like that you can extract the appimage and move it somewhere.
If I remember correctly, I did that a couple of times.
Does it go through a software “layer” like the others do? I am not super into it like I said. If it’s just a binary with duplicate libraries that launches on it’s own I guess I will reevaluate my opinion.
Maybe this will help you to understand AppImages:
Unfortunately, is the tool to extract AppImages an AppImage, but I think you can do it with Ark too.
Michelist
AppImages are an archive with the application and all its libraries, similar to how applications are often packaged on other OSes (.zip on Windows, .dmg on macOS, .apk on Android).
But, perhaps this discussion should be moved to its own thread?
2 Likes
I apologize for the offtopic, I took a look at appimage more and it looks cleaner than the rest. I will raise my opinion of it. Thanks. No need to create other topics.