Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a Flatpak package for Linux #143

Closed
thecursedfly opened this issue Aug 3, 2018 · 14 comments
Closed

Provide a Flatpak package for Linux #143

thecursedfly opened this issue Aug 3, 2018 · 14 comments

Comments

@thecursedfly
Copy link

thecursedfly commented Aug 3, 2018

Hi,

As you may have heard, Flatpak packages are a universal method to distribute applications for Linux.
Anybody can download and install the flatpak applications from flatpak.org (or alternative flatpak repositories).
This is a preferred method to distribute user applications, allowing for cross distro compatibility, no dependency hassles, the possibility to use just released versions even on older distributions, possibility to sandbox the application, and more...

Therefore, please provide a Flatpak package for Linux.

The developer documentation can be found here: http://docs.flatpak.org/en/latest/

Thanks

@tumic0
Copy link
Owner

tumic0 commented Aug 4, 2018

Flatpak packages are definitely not the "preferred method to distribute user applications" on linux. Flatpack is a hack/workaround for non-opensource applications where the authors are not willing/able to prepare standard packages or a workaround for bureaucratic distributions like Debian, where adding a package takes several years.

GPXSee is opensource and with minimal dependencies, so creating a proper package for any sane distribution is almost trivial. Additionally, the latest GPXSee package is provided for 26 linux distributions/versions which should cover most of the "linux world". The remaining users can compile GPXSee from source.

So sorry, but there will be no "official" flatpack package of GPXSee.

@tumic0 tumic0 closed this as completed Aug 4, 2018
@thecursedfly
Copy link
Author

No need to be grumpy (it surely sounds like that); this is a reasonable request seen the recent popularity that flatpak enjoys, in the face of it's features.

I did not say that it is the preferred method to distribute software for Linux, but a preferred method, for several reasons. That, because it allows to sandbox the application, allows to avoid dependency problems once and for all, allows to distribute the latest release to several/all distributions in one universal package, automatically supports any new or old distribution release that supports flatpak, just to name a few good reasons.
For these reasons it's not a hack/workaround for non-opensource applications, but brings actual advantages to any application, including opensource.

There would be no need to provide it for those 26 distributions/versions with a flatpak package, but just one (of course those distributions/versions need to support flatpak, but I believe that is easier than requiring the maintenance of thousands of applications instead). Why require tens of people to waste time packaging and testing the same application for every distribution/version when that can be avoided by doing it just once with a flatpak?
Also stating "the remaining users can compile from source" kinda defeats the purpose of packages at all no? It also requires the users to be more tech savvy than should be required from common users (I wouldn't know where to start for example).

Nice way to greet somebody who appreciates the application and was only trying to help the community by increasing the availability of it.

Anyway, thanks... I guess!

@tumic0
Copy link
Owner

tumic0 commented Aug 4, 2018

Well, there is a need to be grumpy as I really do not want to support the linux ecosystem becoming so fragmented, that every two applications have a different package manager. I want a single package manager on my linux, not python programs being managed using pip, javascript programs using npm, half of GUI applications using flatpack and the other half using appimage...

Flatpack has its usage for non-opensource applications but for "regular" applications it is "no way" for me (not to mention all the problems with the runtimes and system integration). Additionally, creating another package (flatpack) for every release is an extra work that can be spent more useful on GPXSee developement so all GPXSee users can profit from this work, not only an absolute minority.

Don't take it personally, but as GPXSee is a 100% personal hobby project, there are simply requests that I'm going to ignore even when they are reasonable for some individual/group of people.

@ghost
Copy link

ghost commented Sep 27, 2018

Also note that if you provide a flatpak package, you (as opposed to the distribution) become responsible for monitoring known security vulnerabilities in the dependencies and rebuilding and updating your flatpak package as necessary. That's quite a big future obligation for a hobby project.

@ghost
Copy link

ghost commented Sep 28, 2018

Nice way to greet somebody who appreciates the application and was only trying to help the community by increasing the availability of it.

If you want to help community by increasing the availability of application, you can maintain flatpack package yourself (OSS, remember?). You don't help much with making people to do something or talking about it.

@sikmir
Copy link
Contributor

sikmir commented Sep 28, 2018

If you want to help community by increasing the availability of application, you can maintain flatpack package yourself (OSS, remember?).

In support of what you said, I just leave it here:

Packaging status

@sikmir
Copy link
Contributor

sikmir commented Oct 2, 2018

Good news for true geeks. GPXSee is available on Haiku now! haikuports/haikuports#3176

virtualbox_haiku_01_10_2018_23_07_33

@tumic0
Copy link
Owner

tumic0 commented Oct 2, 2018

Good job! The betting odds for GPXsee being in Debian before running on Amiga or ZX Spectrum have just dropped somewhere to 1.1 : 1 ;-)

@sikmir
Copy link
Contributor

sikmir commented Oct 2, 2018

@tumic0 What about applying the patch to upstream? Qt supports Haiku (see Q_OS_HAIKU in qt5/qtbase/src/corelib/global/qsystemdetection.h).

@MarSik
Copy link

MarSik commented May 15, 2023

Any chance you would reconsider this? Five years have passed and Flatpak now IS the prefered way to distribute desktop applications for distros like Fedora Silverblue (even Gnome itself ships a lot of them that way now).

The reasons are that it allows sandboxing (limiting access to user data? easy), installing desktop apps without root, actually using the newest application version on a stable core OS.

In general, there is a growing tendency to separate the operating system and the user applications. Both in terms of library versions and install permissions.

@tumic0
Copy link
Owner

tumic0 commented May 15, 2023

Looks like you didn't get, who "Pacoš z Bohnic" is... ;-)

@MarSik
Copy link

MarSik commented May 17, 2023

I did. Or guessed. However I stand behind my arguments from that other discussion. The desktop application ecosystem has evolved significantly over the last five years.

Even your package version list illustrates the issue. Fedora has 12.3, Arch 13.2, Gentoo 13.1, Manjaro stable 12.4, openSUSE Leap 11.12 and Debian nothing (as we have discussed and joked about).

Users nowadays want a stable OS with the option to switch versions as needed to resolve driver and OS level issues, but at the same time they want the latest and greatest desktop applications. And they do not want to care about library versions or dependencies that prevent having the latest app or about needing administrator rights. Sometimes (probably not the case for GPXSee, but FreeCAD for example) users actually want to have two versions of the same application installed at the same time.

My personal preference is Flatpak as I have explained, because

  • it is native in Gnome and supported by Freedesktop
  • it runs on all modern distributions (Snap requires AppArmor and disabled SELinux)
  • is automatically updated (AppImage does not for most people) and shares Runtimes
  • allows 3rd party repositories so no vendor lock-in like Snap effectively used to have)
  • Flatpak also sandboxes the application and can restrict access to resources and user data (again as opposed to AppImage). This can be important when you process untrustworthy data. Parsing bugs do happen...

RPMs, DEBs and other binary formats cannot provide this and more and more projects (desktop GUI apps to be exact) are moving to either AppImage or Flatpak. Snap adoption and support seems to be limited compared to the other two.

@tumic0
Copy link
Owner

tumic0 commented May 17, 2023

I did. Or guessed. However I stand behind my arguments from that other discussion. The desktop application ecosystem has evolved significantly over the last five years.

First of all, the desktop (and Linux desktop especially) is dead and I would not call that an evolution...

Even your package version list illustrates the issue. Fedora has 12.3, Arch 13.2, Gentoo 13.1, Manjaro stable 12.4, openSUSE Leap 11.12 and Debian nothing (as we have discussed and joked about).

I do not see an issue here. Distros that have good processes and active community keep up very well with GPXSee developement (there are only 14 days between 13.0 and 13.2). Distros that have releases frozen in time like openSUSE Leap are expected to have older versions. It is your choice what kind of system you like.

Users nowadays want a stable OS with the option to switch versions as needed to resolve driver and OS level issues, but at the same time they want the latest and greatest desktop applications. And they do not want to care about library versions or dependencies that prevent having the latest app or about needing administrator rights. Sometimes (probably not the case for GPXSee, but FreeCAD for example) users actually want to have two versions of the same application installed at the same time.

I don't think so. Most users do not care how old their SW is as long as it does what they need. The developers (me included) think that every minor change in their SW is super important for the user, but usually it is not. And when you really need a brand new version, you can always go to GitHub and compile it yourself. Yes, that may be tricky for the Average Joe, but Linux is not a system for the Average Joe and I do not want it to become such, because than we would end up with a copy of Windows (there is nothing bad about Windows but we already have this kind of ecosystem). Which is exactly where all this Flatpack "attempts" are going to end - in a much more closed ecosystem than today ruled by some big corporation. It's not a coincidence that the biggest promoters of such systems are RedHat and Canonical.

A system, where the SW developers are "forced" to create their software compatible with multiple distros makes the SW better as it prevents the mess that you can today see in the JavaScript world or amongst (corporate) Windows software. It also produces innovative distros like Arch linux or NixOS instead of something like Android.

My personal preference is Flatpak as I have explained

I have no problem with your preference as long as you do not force others to see it the same way. You love Flatpak? Then build yourself a Flatpak package. GPXSee is opensource and creating the Flatpak is easy-peasy according to all the Flatpak evangelists...

RPMs, DEBs and other binary formats cannot provide this and more and more projects (desktop GUI apps to be exact) are moving to either AppImage or Flatpak.

Don't confuse RPM/DEB with RedHat/Debian. It is the distros, that are not capable not the binary formats. RHEL/Debian is definitely not suitable for a modern desktop (which is dead anyway...), but there is much more in the Linux world than Debian/RHEL.

@MarSik
Copy link

MarSik commented May 18, 2023

I am not going to ask you maintain the build yourself, but I think you are too pessimistic about linux desktop and the recent development. And you obviously have some very inaccurate information (and bias against corporations :)

Which is exactly where all this Flatpack "attempts" are going to end - in a much more closed ecosystem than today
It's not a coincidence that the biggest promoters of such systems are RedHat and Canonical.

Flatpak is actually a Freedesktop project. And natively supports 3rd party repos, anyone can setup one. So no vendor lock-in (Freedesktop itself belongs to the X.org foundation)

Flathub is also not directly related to RH or Canonical in any way. It is backed by Freedesktop and CNCF (again, a foundation with a long list of very diverse members).

RHEL/Debian is definitely not suitable for a modern desktop (which is dead anyway...),

So think about Fedora, or Fedora Silverblue (no RPMs, ostree based). Flatpak is the prefered way to install user applications there.

Speaking about NixOS: The docs and https://matthewrhone.dev/nixos-package-guide also mention Flatpak

And so do Arch and Manjaro in their docs.

Most users do not care how old their SW is as long as it does what they need.

Strictly speaking you are right, but...

This commonly maps to demanding the latest features possible. Not all users use all the features of course, but think about your user base. GPXSee is a tool that will be predominantly used by technically savy users and those often do adopt features quickly.

GPXSee is opensource and creating the Flatpak is easy-peasy according to all the Flatpak evangelists...

It could be easier, but it depends on the amount of dependencies the app has. GPXSee will probably not be that hard.

But of course, scratch your own itch and all that. So whoever is interested should do the packaging work.

This should be an issue tracker and not a discussion so I apologize for the polemic. I was a bit annoyed by the grumpiness and the inaccuracies in your perception of modern approaches to packaging desktop apps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants