From @lipu
Reading through this thread, I get the impression that some people think maintainers are
a dime a dozen. They’re not, especially not in a company the size of Purism
It’s normal, you first need to bootstrap. For the moment, I do not think that PureOS
is widespread like Arch, Debian, Gentoo, CentOS, etc. It’s because it is, for the
moment, not widely adopted that there is not enough maintainers. If your distribution
gather enough people, you will have maintainers. Arch, Debian, Gentoo, etc do not
have problems with packages…
As a side note, and correct me if I’m wrong, my understanding is that a flatpak is built for a specific processor and thus not portable across architectures. Flathub is for Intel/AMD only - at least I see no place where I can select anything else there. The Librem 5 will have an ARM-based chip, which is completely different. So, the flatpaks currently available from Flathub will not be usable on the Librem 5.
Yes your probably right, you caught me. But nothing prevent Flathub to create ARM apps
specially for the Librem 5.
I think it’s unfair to compare flatpaks to the Windows “downloading random binaries from the internet” model. It’s true that apps bundle libraries, but flatpak really provides a middle ground between the traditional, fine-grained, repository model and the “bundle everything” model.
All the base libs are contained in runtime modules, that are shared between apps and updated separately. Other libs are bundled with applications.
Each flatpak packages can pack whatever libraries It wants. So yes, flatpak bundled
packages like Windows. Saying that some libraries are globally used using “runtime”
does not change that fact.
Moreover, here I’m not sure about the following, but, at first look in the doc, runtimes
are hosted in Flathub and so the distribution are not in the control (Flathub manage
the runtime updates, etc).
Whether this is better or worse than the situation with distro-provided packages is not so clear. […] In the other hand, replacing a lib may break installed apps that depend on a certain version, and distros have been known for shipping outdated libs for years (e.g. WebkitGTK) because some packaged apps were not updated to use the newer version.
This is an interesting remark but honestly do you think that it’s better to have some packages
with the new updated library if all the rest of your package use the old one ? I think that it’s
better to change the source code of the majority to support the new library and then, after,
force the old library transition on all apps. Moreover, do you think that the library transition
will go faster (or will even complete) if each package knows that its libraries will always work
due to flatpak ?
Of course, adding malware to apps outside of Purism repositories is still possible. But is getting a flatpak from a random place really any different from getting a .deb from a random PPA?
There is two problems that make it worse :
1. It makes the software run reliably in the time
2. It makes possible to create one package to infect all distributions
So, with flatpak, it is much more easier to develop one package to
rule them all and this gives tremendous power to software providers.
From @jeremiah
Sadly, this is an idealized description of the roles of developer and maintainer. Oftentimes the developer is the maintainer and decides on using a particular packaging technology, like a tarball, and they don’t care about other formats, like rpms, flatpak, snaps, etc.
A maintainer will probably be a dev for the distribution that he loves and this does
not shocked me. This is not a problems because, even if it’s a dev, it must comply
with maintainer rules or it will be fired (and if no other maintainer takes its package,
it will not be able to integrate it anymore).
A maintainer for your favorite distro is then a good thing to have. But even if you have a maintainer for your distro, it doesn’t mean that there is suddenly a layer of security, even if your distro is Debian. Maintainers are human and mistakes can and do happen, this is why isolation is important – if you limit access to only one means of IPC, you limit the amount of damage a mistake can cause.
Once again, I’m not against isolation but does isolation imply packing libraries ? Why do you
associate the two ? Namespace, cgroups and seccomp do not depends on libraries. Thus,
you can have a package description format that do not pack libraries and integrate isolation.
I don’t understand this statement. Portability can mean porting applications from one distro to another, from one Desktop Environment to another, from one chip architecture to another, etc. It has little to do with obsolete programs.
I think that you make a confusion, I’m not talking about portability
in general. I’m talking about portability in the context of flatpak
which mean packing the libraries into the package. All these arguments
refers to source code portability which is different than packing libraries.
Note: I think that it is good if all distribution will reach agreement
on 2 or 3 package formats (and thus on 2 or 3 package managers).
Convergence on some universal package formats are ok but these format
must not enable the packing of libraries.
This portability is what is killing maintainers.
You’ll have to provide more evidence.
Ok, I have a bit overstated this but the truth is that the goal of flatpak is to give
full power on devs. And, now, you know what I think this means for maintainers.
In my opinion, it goes even further, flatpak was developped with major goal to
enable users to install and use reliably prorietary softwares on Linux. Precisely,
it was developped to make possible and App Store or an Android Store on all
available Linux distributions.
We want everyone to be able to have freedom, regardless of which OS they run. So apps that Purism creates need to run on the largest possible installed base.
You can distribute flatpak packages without accepting them.
A foundational tenet of Free Software is to not exclude any field of endeavor, instead of imposing restrictions, it grants rights to other people, and one of those rights is to make any kind of application you like as long as you comply with the license. We cannot impose any restrictions on ‘external’ software, nor should we.
It’s not about restricting or preventing user to install external software by all means. It’s about
not promoting a technologie whose major goal is to ease the installation and proliferation of
external software (weakening maintainer curation). You should add flatpak in your repository
(sometimes this can be useful) but you should not promote it. Conversely, I’m not against
using this technologie to promote free software.
Portability is a foundational requirement for collaboration on applications, this is how you get Fedora developers interested in working on applications and libraries in Debian.
Ok, this argument is a good one but not enough for me. Let’s face it, you already share
your packages with Debian. All packages on main should be mostly ok without revision.
The remaining packets that you do not want to share with Debian is because you have
a different philosophy than Debian.
If, in the future, there is too much similitude with another distrib, you can just fusion
with this distribution.
Even with all these packages shared, do their are enough packages that other distribution
will want (as the other distributions by definition have other philosophies than PureOS and
so do not share globally the same packages than PureOS). And even if yes, does this really add
enough value to really worth all the drawbacks ? Serious question.