PintaProject
Add AppImage release building
Description
It would be very nice to have for the GitHub an AppImage release for Pinta especially for the 2.2 dev build. Apps like Gear Lever make AppImage integration quite easy although the compression algorithm should be considered as I believe AppImageLauncher is not maintained actively and newer AppImages built with zstd may fail.
Are there many libadwaita AppImages already?
Whilst I think Pinta would usually be a good candidate for being an AppImage, AppImages have to be built on the oldest stable distribution possible. Focusing on Ubuntu, Pinta would build on Ubuntu 24.04 but not 22.04; any AppImages would be implicitly only supported on 24.04+; and the GTK4 features in use are pretty new, I don't think Pinta 2.2/GTK4 would build on Debian Stable as is.
The result would likely be something most people expect to "run anywhere" but that doesn't run in most places.
I would like appimage too. I don't use flatpaks or snaps because they tend to download gigabytes of extra stuff. Appimages might not be as secure, but they're easier to deal with.
The Pinta snap is 50MB, when including the Gnome and Core dependencies, it's about 350MB. That's smaller than the Windows installation of Pinta in its entireity (that's about 500MB) and 90% of the dependencies it uses deduplicate with other snaps that need them, there's a truth to the idea Snaps and Flatpaks can be large but it's not applicable in every situation and I'd honestly argue not even applicable to most when the maintainer knows what they're doing.
For an AppImage to be made and retain universal compatibility, GTK4 and .NET8 would need backporting to something like Debian 10 or RHEL7, to then have Pinta built on a distribution that's 6 years old with libraries never designed to be compatible with it. Otherwise, it's going to be an AppImage that runs on Ubuntu 24.04+, Fedora 40+, etc. It's not unusable, but it's also absolutely not going to be anything as widely supported as what most people think with JRE, Electron, etc, AppImages.
I'm not against AppImage where it makes sense as a technology, but I'm still curious if there's generally any GTK4/Libadwaita AppImages, my expectation is probably not many, but maybe someone's put the effort in.
I wish an AppImage or install Pinta on Debian from their official repositories.
Canonical is contrary to GNU: https://www.gnu.org/philosophy/ubuntu-spyware.en.html
Well a hypothetical GTK3 AppIkage might work.
But a GTK4 AppImage is going to involve back porting software tool chains 6 years and possibly outright reverting patches that have already been submitted. That's the implicit ask here. Remove functionality from users who can use it to give to people who'd rather have nothing than something.
It's not a strong argument but I wish you luck with it.
I agree with @JGCarroll that this doesn't make much sense at the moment with the current dependencies of Pinta's master branch, since the appimage would have very limited compatibility. I don't have any objections otherwise so in the future contributions to setting up a package would be welcome.
@satonotdead re: packaging Pinta in Debian's official repositories - that should be filed as a request with the Debian packaging team (it's not an upstream issue). Pinta used to be packaged by Debian, but hasn't since Pinta 2.0 because Debian doesn't yet support packaging .NET applications
If this AppImage ever becomes reality, please make it available for Aarch64 too! ;)
Pinta used to be packaged by Debian, but hasn't since Pinta 2.0 because Debian doesn't yet support packaging .NET applications
Please correct me if I'm wrong, but it appears that in order for a package to be included in Debian's main repository it has to be buildable, directly or indirectly, by a core of Debian's trusted tools, like GCC. Normally, one would use those to compile the toolchain for the language and platform in question, or follow a chain of compilations that makes that final compilation possible. But since most of .NET is written in C# one runs into a bootstraping problem. Right?
In that case I understand why one wouldn't include .NET software in the main repository, but isn't there any way to include it in the contrib or non-free ones?
.NET is MIT, I'd expect ultimately no one has offered to package it, moreso than it not being wanted. I'd have thought it were a good candidate for main personally.
@JGCarroll indeed, the code is under the MIT license, but (if I understand correctly how Debian works) how would one solve the bootstraping problem (circular dependency on the compiler, since the code itself is written in C#)? Otherwise it would be very strange that nobody has offered to package it, .NET is too important to be set aside like that.
Fedora is packaging dotnet in it’s Core and has very strict license policies, too.
@badcel my understanding is that Fedora has a formal bootstrapping exception for packages like .NET
Afaik it is possible to Build dotnet under Linux without the need of a dotnet binary first.
The code from fedora at least looks this way, too: https://src.fedoraproject.org/rpms/dotnet9.0/tree/rawhide
Seemingly they create the bootstrapper from source first.
See here, too:
- https://github.com/dotnet/dotnet
- https://github.com/dotnet/source-build
Which reads like building from source is already supported for Linux.
Thank you @badcel, I think the existence of the source-build project and its explicit mention of Fedora and Debian answers my question, or at least points in the right direction.
Don't forget Ubuntu has C# and while the policies might differ between Ubuntu and Debian, it'd be a good idea to investigate the Ubuntu archive and how that's built and packaged since it'll be very close in at least the runtime stages, if not most the packaging.
I would like an AppImage for (actually Debian 12, KDE). In general, I like the concept of portable apps, but I have not tried Pinta yet. I would if an AppImage released.
https://github.com/pkgforge-dev/Pinta-AppImage
That looks really cool! Lots of neat new stuff in there.
https://github.com/pkgforge-dev/Pinta-AppImage
This is great! I've filed https://github.com/PintaProject/pintaproject.github.io/issues/19 to get this linked to from the Pinta website, so I think this issue can be closed