You may be able to do that with different versions of the same Linux distribution, if they provide some kind of a stability guarantee. It is not really possible to build programs that will work across all versions of every Linux distribution. Different distributions can have incompatible base systems and incompatible kernel patches, making it impossible to build a package that works everywhere. Depending on who you ask, this is either a strength or a weakness of open source operating systems…
Thank you Jason,
This is now beginning to make some sense to me.
Perhaps this is the reason in the Ubuntu Store reviews, one user will sing an application’s praises while the next user says it won’t even run - or it crashes every time its run.
Many thanks
Malcolm
Sort of. In the simplest scenario a C developer will write C files and a couple of files in another language that will constitute the package’s build system.
The package’s build system has some installation capabilities, but does not have the capability to indicize the package in a distribution’s database.
Therefore, when a distribution maintainer will package that program for their distribution, they will exploit the package’s build system only for creating a staged install: basically they will tell the package’s build system that a local temporary subdirectory is the root filesystem and they will “install” the program there. They will then package that subdirectory according to the specific distribution’s needs, and add to the package all the necessary information concerning dependencies (this info usually comes from the README file and from distribution-specific diagnostic programs). This process is done once, then automatized in a package manifest file.
Attempts to create distribution-agnostic package formats or package managers face different reactions depending on personal opinions and how such agnosticism is implemented. Personally I thought that PackageKit was a great idea, because it was built on top of diversity, while Flathub and Snap follow the opposite approach.
The paragraph you are talking about is “The installation disc(s) would then become the ‘Master’s’ for me to create and distribute duplicates”. The answer on GNU/Linux is complicated. What comes closest to it is the concept of reproducible builds, but that won’t change the fact that different scenarios will require different builds.
In theory the impossibility is only that of distributing a compiled package that works on every distribution – but the source files will solve this problem (and this is why each distribution has its own version of the binary package). Within the same distribution however the same binary package should work for everyone – assuming that all users keep the system up to date and no hardware (drivers) is involved.
That said, whatever OS and packages you choose, errors are always possible and human.
―madmurphy
Huh? This is the exact opposite of how it actually is. Flatpak and Snap are set up similar to Docker or any other containerization approach. They became used precisely because distros are all hopelessly incompatible and cannot handle the diversity of having more than one package manager, so the only way to deal with it is to put the base system in a container. They are solving a completely different problem from PackageKit, as PackageKit cannot really do anything about the diversity of packages. It only has an effect for a very small number of packages e.g. GNOME Software and similar.
Jason, this discussion is not easy. I know that there are people here who invested their time in Flathub, and I am just a guest. However I do have opinions, so I will just speak sincerely according to how I think, hoping that mine can be considered at least as a possible user feedback.
With PackageKit, if GNOME wanted me to install foobar, a dialog window would appear, and if I said YES, GNOME would ask PackageKit to install foobar, then PackageKit would ask my package manager to install foobar. My package manager knew foobar, which had the XXX build system before being compiled but now it’s just a compressed archive like all the other packages. And so it would install foobar.
It was a perfect pyramid, in which different build systems were standardized by package managers, and different package managers were standardized by a meta package manager, PackageKit. All the granularity was preserved, and yet GNOME was still able to ask, simply, “install foobar”.
Today Flatpak works on my distribution, so GNOME can ask Flatpak instead to install foobar and the job will be done. However my package manager will not know about it, and so the user (read: me) will have to remember that foobar was installed by Flatpak, in case it will need to be uninstalled at some point.
And let’s imagine that GNOOME (a fictional name for a fictional environment installed on my machine) will need Snap instead of Flatpak, and will need the helloworld app: now I will have to remember that helloworld was installed by Snap, in case I want to uninstall it.
And so simplicity is gone. No more pyramids, only neighbouring buildings, and instead of one package manager now I have three.
For me PackageKit was the first (and last) tool that gave me the feeling that the package manager I had chosen was actually respected by my desktop environment.
I am pretty sure that GNOME developers do have respect for all, or at least most, package managers. So why not showing this respect and keeping the ambitious plan of building a unifying project?
This is what I sincerely think.
―madmurphy
PackageKit and Flatpak do not solve the same problems.
PackageKit is all about having a common language when something to install is requested regardless of the package format (e.g. deb, rpm) of a distro. Flatpak and Snap consist of providing applications that work on all distributions (but require the installation of flatpak and/or snap). AppImage has the same intent as Flatpak and Snap, except that the app cannot be sandboxed with this system, but can be run without installing additional software. With Flatpak/Snap/AppImage apps, developers can deliver apps that may be more up-to-date than the versions provided by a distro.
Additionally, Flatpak/Snap/AppImage apps are complementary to current package formats. And GNOME does not ask Flatpak to install an application but Software which asks to choose the installation source (flatpak or package format of your distribution).
That is noble.
Maybe I come from a different school… In my opinion a distribution is, above all, its package management (and so if package XXX is missing in the repositories of distribution YYY, this bug won’t be solved until package XXX appears in at least some repositories of YYY, no matter if in the meanwhile the user is able to install it from source, via flatpak or by praying). Of course, a distribution is a lot of other things too…
The main reasons why I still don’t understand Flatpak’s place in all this might be the following (but maybe it’s truly a limitation of mine):
- If Flatpak’s goal is that of providing software not provided by a distribution, it is destined to have very few users on Debian, Arch, and a bunch of other big distros with dozens of thousands of packages
- If Flatpak’s goal is that of providing the latest version of a package, it is destined to have very few users on rolling release distros, where the time lapse between a release upstream and a distro release happens within days, but with added support for the specific distribution
- If Flatpak’s goal is that of being “the standard” in package management, it’s a lost battle: the field is and still will be an active research, in which cool new ideas will keep coming
- If Flatpak’s goal is that of convincing developers to create at least some compiled package of their app, not just the source code, that is going to be too much to handle for a lot of developers
That said, being unable to understand Flatpak’s place might truly be a limit of mine, and in that case I apologize for my shortsightedness.
Yes, I was just being synthetic – same with PackageKit (GNOME would ask gnome-packagekit to do the job, not directly PackageKit)…
―madmurphy
No, in either case you would just use PackageKit again (via GNOME software) to uninstall the applications. I am confused again here, why are you thinking it is only possible to install things with PackageKit and not uninstall them?
I can see why you would think those things initially, but even now I have seen packages that are are in Flatpak repos but are not in some rolling release distros. Additionally, Flatpak is insulated from all the other breakage and instability caused by rolling release — the packages can be pinned to a particular platform version and they will keep working. With a typical rolling release distro the packages have to be updated and kept in sync with the rest of the system or they will break. Just look at all the complaints recently about Python 2 packages breaking. Of course you can avoid this if you use NixOS or GuixSD because those are conceptually similar to the way Flatpak works with OSTree.
I think those are bad things to say. By that logic, every other distro should stop developing package managers, and developers should never bother trying to support any binaries at all…
If I may chime in as an app developer, I much prefer using Flatpak to develop them and distribute them on Flathub.
For one, it guarantees me that the environment I use to develop and test the app is the same that the user will be running, no matter their distribution. That eliminates packaging issues with incompatible libraries or missing dependencies, and I get error reports directly if something doesn’t work as expected, most of the time in a reproducible way.
Second, Flatpak users get updates as soon as I publish them, meaning they get new features and bug fixes immediately. For example, on Ubuntu repositories, one of my app is out of date by a whole major version, released one year and a half ago. It’s totally unsupported, but what can I do about it when users complain that something is broken? Nothing, because the distribution mechanism is totally out of my hand.
Third, Flatpak and Flathub make my app instantly available. I don’t have to wait for packagers of a distribution to notice the app exists, take some of their time to package it, and then commit to updating the package regularly. In fact, of my two apps, one is not available in any distribution, even though it has been released a few months ago. This is an important point, because it makes the ecosystem dynamic and lively: developers of new apps get users immediately, and can quickly iterate on the feedback to improve their apps. That means it’s more appealing to develop new apps, and users benefit from that.
1 Like
What I was saying is that PackageKit is just a wrapper for my distro’s package manager, so installing/uninstalling works just like it would with my distro’s package manager, whereas Flatpak/Snap/etc are separate environments that might double the amount of things I will need to keep track of…
But then we go back to what I was saying earlier: a distribution is above all package management; and I must add another thing: people choose that. If I use Slackware most likely I want an almost-frozen system that I will never have to update ever again, while if I use Debian I don’t dislike having packages a bit outdated, whereas if I use GuixSD or NixOS probably I want that kind of sandboxing that you mention. I actually think that I resisted so far from installing GuixSD or NixOS because at the moment I want a traditional rolling release experience like the one offered by Arch, in which the whole system needs to be kept up to date and no rollbacks or version forks are possible.
So if Flatpak’s place is that of being another distribution, probably together with NixOS and GuixSD as its closest neighbours, I understand its place and I am fine. I might even try it that day in which I want a Nix/Guix/Flatpak user experience. But if its place is that of integrating my package manager of choice, then Flatpak might be forgetting that I chose my package manager of choice…
By the way, I have the exact same argument against the fact that Guix is installable also on other distributions and not just on GuixSD. It’s not really a strong argument as long as I can choose not to install Guix on my distro, so it’s actually OK. But my fear is that Flatpak becomes so integrated in GNOME that I might not be able to avoid it in the same way as I am able to avoid Guix – I have absolutely nothing against Guix, which I actually consider one of the freakiest and most interesting experiments in package management.
The truth is that already now flatpak-builder is a mandatory dependency of gnome-builder on Arch, and so I wonder how much it will become more and more mandatory in the future.
―madmurphy
Hi Romain,
Thank you for sharing your experience. Just some random thoughts:
A risk associated with that is that it might possibly make your app less robust in the long run. In the old fashioned world, I release FooBar, I try it on FantasyDistro and it works, but you try it in DystopiaDistro and it crashes. Then you write to me, I fix the app and now it works on both FantasyDistro and DystopiaDistro. Your app instead, which was tested only in a golden environment, might give no information about its robustness. You might argue that that won’t be necessary the Day of the Great Revelation, in which everyone will use Flatpak and only Flatpak. But no, that will never happen.
Of course, in the real world I am sure that you did all the right tests. Mine was just storytelling.
I understand that, and I even agree with you. My answer to that is usually that of considering non-rolling release distros a thing of the past and so I don’t bother solving their structural problems – everyone will convert to rolling-release eventually.
On the other hand, I am usually pleased by the ready response of rolling release distros when I release an update.
I have only one argument here: for early testing I would prefer that only power users put their hands on my app. Compiling from source puts a natural threshold on who is able to test my app early, while making the app instantly available “for everyone”… good luck (to your testers)!
That said, compiling from source is boring also for power users, so I am sure those won’t complain if they have a binary available.
―madmurphy
GNOME has to be impartial to the distro and Flatpak is currently one of the only real options for that. If distro maintainers could ever agree on anything, then maybe this would not happen. But they cannot, and historically this has only gotten worse. Even with the method used by Nix they cannot agree, because some developers decided to create another implementation (Guix) that used Scheme instead of Nix language and was therefore incompatible…
There is where I disagree a bit. I think that PackageKit is impartial and trusts the distro, whereas Flatpak overrides (exactly like any other foreign package manager). Flatpak might really be the perfect package manager for a GnomeOS though (or any other Flatpak-only distro).
I would also like to emphasize that my concern is not about Flatpak or Guix or any other package manager conquering the world like a sort of space invader, but it is that of not making GNOME more and more reliant on a particular package manager.
I quite agree on the factual description. But I would like you to make an excercise: transform the negative adjectives into positive ones, and try to look at the positive sides of this landscape. Having different package managers available, each with a good user base, suggests that the needs that each package manager gives answers to might actually be real needs (and so it is good that the answers do exist), and having different languages might be where diplomacy flourishes the most.
I am also not really sure that the actual number of actively maintained package managers has increased. By instinct I would say that only the number of distributions is larger, but these tend to be more and more distributions derived from other distributions. So, that might be another positive element too – although I think that if someone has a revolutionary idea about package management they better create a new package manager than throw the idea into the trash.
―madmurphy
The base system to run GNOME and Flatpak in the first place cannot be installed with Flatpak, so this is not a reasonable concern.
Sorry, I will have to decline this. I did that for many years, making excuses for various weird selfish behaviors from distros. In my view, whatever victory they get now is pyrrhic, the task has now become an exercise in corralling all the other incompatibilities created by the rest of the community and most of the effort is duplicated to re-package the same base packages over and over again. They can rewrite their own little part in whatever language they like, but the rest of the world will just keep on going and continue using the same popular languages, Javascript, C++, Python, etc. There is often no money involved so the only thing keeping any of these things going is raw ego; nothing will ever be good enough for some unless it fits some arbitrary definition of “purity” that some distro has determined. It is honestly so exhausting, time-consuming and petty dealing with this circus at times, that I would not blame users like @Dragonfly for ignoring this altogether. Can you really blame some developers for cutting out this middleman and just going with Flatpak or Snap?
Not at all! I am always happy when people act according to their real wishes – if they were able to do that during elections the world would be a better place.
When I say that I am skeptical I mean that I am skeptical that this is able to answer a collective wish (but I can always be proved wrong).
―madmurphy
I can only disagree with this. Most of the bug reports I get from traditional packages are issues with the host system or the packaging, nothing I can do about as an app developer. Robustness is not “coding a lot of workarounds to make sure everything works in the most exotic environments”. In the meantime, there’s a working, up-to-date version available as a Flatpak.
Well, when you develop a new app, you don’t have “power users”, whatever they are, you don’t have users at all. You have to put your app in the real world to have it used, and get feedback from the users. And, currently, the best and quickest way to have users is to publish on Flathub.
That’s another advantage of Flatpaks: the repositories of my apps contain the Flatpak manifest, which describes how the app should be built. If anyone wants to build development builds of the app, they only need the manifest and the flatpak-builder tool, no need to install development packages and track down dependencies, everything is built in the Flatpak environment. That makes testing and contributing much easier since you don’t have to setup and configure a build system.
Of course it’s not. But I am pretty sure that either you are the unluckiest of developers or a good portion of these reports actually made sense and suggested you to pay attention to things you didn’t think about before.
But, most importantly, you don’t need to agree to all requests in order to write robust code, you only need to be aware of them (and then decide accordingly).
See? You just wasted your time creating a package instead of making your app more robust! 
(I am joking, I also release packages – even binary tarballs – when I release a new version)
It’s really not very different from just using Arch…:
- Create your source repo (use whatever build system you prefer)
- Create a
PKGBUILD(about 20 lines) - Publish the
PKGBUILDon AUR
―madmurphy
I think you misunderstand. New testers and contributors are not trying to publish new builds to a repo, they are just trying to build the package locally so they can contribute. It is not reasonable to ask them to switch their distro to Arch just to do that. You can assume they do not know anything about flatpak manifests or PKGBUILD or debian/control or any of that.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.