[Wiki] Add a template for Flatpak packages

NeoTheFox · 2018-01-26 12:57:28

I propose adding a template for flatpak packages to the wiki, just like we have for AUR packages.
This would promote flatpak usage among ArchLinux users and make installation of software that isn't in the official repositories easier for the end user.
My argument is that in accordance with Pragmatism and User centrality principles promoting flatpak is a good thing, because:
1) It is in the repos
2) It doesn't require building/packaging on the user machine
3) It is more secure than AUR since the packages are sandboxed
4) It doesn't promote tools such as AUR helpers which are known to cause problems as recently as with pacaur/cower server load
5) There is no need to install build dependencies to install a out-of-repo package
6) Users wouldn't experience breakage because of package abandonment

Take Nextcloud for example - the nextcloud-client is not in the repos currently, and is available from FlatHub. The official way of dealing with AUR without additional tools would require a whole process for installing just this one package, where flatpak would be installed with just one command and little to no user involvement.

How I suggest using flatpak template:
1) Prioritize repo packages over flatpak, but flatpak over AUR by order
2) Stress that Flatpak packages are unsupported

Trilby · 2018-01-26 13:13:38

So you've presented reasons why you think flatpack is good. But what is your actual proposal? What do you want to convince this community to do?

No action seems called for. As you note, flatpak is already in the repos. If an arch user whats to install nextcloud from flathub, they certainly can. I don't see how/why any "template" is needed or what this template would be.

edit: ooh, a wiki template - sorry I missed that part. But still, what would this template be? AUR templates link to our AUR, the repo package teplate links to the package in our repo. What would a flatpak template link to? Just flathub?

Create the template, then it can be reviewed. As is this just seems to amorphous to comment on.

Last edited by Trilby (2018-01-26 13:16:37)

NeoTheFox · 2018-01-26 13:17:05

Trilby wrote:

So you've presented reasons why you think flatpack is good. But what is your actual proposal? What do you want to convince this community to do?
No action seems called for. As you note, flatpack is already in the repos. If an arch user whats to install nextcloud from flathub, they certainly can. I don't see how/why any "template" is needed or what this template would be.

Oh that is really simple. There is a template for AUR, which is widely used on the wiki, I want the same format for flatpak packages.

{{flatpak|package}} would do nicely, and I also want to have a discussion on how it would be resolved on click and on hover.

Trilby · 2018-01-26 13:19:50

Sorry, I was posting my edit as you posted the clarification. That makes some sense. But their doesn't seem to be a singular flatpak source. There could be a flathub template, but I don't know how useful that'd be. There'd be a different template for each flatpak source. And at that point, the templates stop serving any purpose at all. The wiki already has links. Just use a link to the flatpak source.

Templates are for wiki code that is regularly reused. What code is being reused here? (none that I can imagine).

NeoTheFox · 2018-01-26 13:26:16

Trilby wrote:

Templates are for wiki code that is regularly reused. What code is being reused here? (none that I can imagine).

That's what I want to discuss, since I lack proper wiki knowledge to create such a template myself. Yes, it is true that there are multiple flatpak sources, but the flatpak team is actively pushing for unified naming of packages, so all packages from different sources would be named the same. For example "org.darktable.Darktable" would always be a Darktable application, no matter what source it came from. The template can resolve these names from FlatHub indeed, and from some other sources too. I suggest following the upstream on that.

eschwartz · 2018-01-26 13:30:10

1) There are many things in the repos. debootstrap is in the repos, but does that mean we are desperate to promote the use of Debian for VMs and chroots?
2) Why is this a problem? It isn't hard to build on the user machine. Building stuff yourself in order to better integrate with the system, is an actual positive goal which makes AUR packages superior to flatpak.
3) You've been lied to. You can sandbox any application using bubblewrap, not just flatpaks.
4) We don't promote tools like pacaur/cower, but people use them anyway. Recommending flatpak would not help with that, as most packages do not have flatpaks, therefore most packages would still be installed with pacaur/cower. Also the cower server load had nothing to do with pacaur, and it also applies equally to anyone who has 50 flatpak packages and just one AUR package. So encouraging flatpak would not help with that.
5) This is just #2 repeated for the sake of redundancy.
6) There is plenty of other breakage they can experience instead, like broken flatpaks. Do you really think all flatpaks work okay, just because upstream packaged it? If so, I have a Windows OS to sell you...

...

tl;dr

There is *no* reason to try pushing flatpak as superior to AUR packages, and I very much doubt our Wiki admins will agree with such a distro policy.

If a template would ease the process of writing links, then sure, that could be done... but that isn't so clear.

Last edited by eschwartz (2018-01-26 13:37:21)

NeoTheFox · 2018-01-26 13:47:31

Eschwartz wrote:

1) There are many things in the repos. debootstrap is in the repos, but does that mean we are desperate to promote the use of Debian for VMs and chroots?
2) Why is this a problem? It isn't hard to build on the user machine. Building stuff yourself in order to better integrate with the system, is an actual positive goal which makes AUR packages superior to flatpak.
3) You've been lied to. You can sandbox any application using bubblewrap, not just flatpaks.
4) We don't promote tools like pacaur/cower, but people use them anyway. Recommending flatpak would not help with that, as most packages do not have flatpaks, therefore most packages would still be installed with pacaur/cower. Also the cower server load had nothing to do with pacaur, and it also applies equally to anyone who has 50 flatpak packages and just one AUR package. So encouraging flatpak would not help with that.
5) This is just #2 repeated for the sake of redundancy.
6) There is plenty of other breakage they can experience instead, like broken flatpaks. Do you really think all flatpaks work okay, just because upstream packaged it? If so, I have a Windows OS to sell you...

I don't think that debootstrap is a fair comparison, as VMs and chroots have limited usage and I think I've seen it mentioned where appropriate on the wiki. Flatpak however isn't mentioned where appropriate, so a lot of users are unaware that this is an option of installing packages on Arch Linux. I think it's important to present users with options where possible.

As for building on the machine it can be a positive, but not always. And sure, if it is not a proprietary package it's better off when built. However AUR is filled with *-bin packages, which are usually repackaged from .deb packages. I wouldn't argue that this is a good way of distribution, as it takes extra time and CPU load just to shuffle files around from one archive to another and then inflate the last archive. Building bigger packages, such as Chromium also takes a while, and can have negative implications for low-power hardware, as it may take hours. There is also a problem of maintaining AUR packages, AUR quality is inconsistent, and sometimes packages in AUR stay broken for a while. I don't want to turn this into AUR vs Flatpak argument, since I am not proposing replacing AUR with Flatpak, I am only arguing for informing users about more options available to Arch users.

I don't know where I've been lied to. but using bubblewrap is something a use have to do consciously, while Flatpak provide sandbox by default, and strong defaults are always better than weak defaults.

The point here about cower was that if a used don't have to use these tools and instead resorts to what's in the repos (flatpak) it's better then using unsupported automated tools that also promote insecure practices like installing AUR packages without reading a PKGBUILD.

And sure breakage can come from multiple sources, I am not trying to claim that flatpak is silver bullet. However as an option I think it deserves inclusion into some wiki articles, and a template would archive this goal.

Trilby · 2018-01-26 14:05:04

Whether or not to promote flatpaks is clearly controversial. I agree with Eschwartz on every point. I think I must have actually been at just the optimal caffeine level in my first response to not vent my disdain for flatpaks here

However, I see the discussion on whether flatpaks are worth including in the wiki as secondary in this case. I don't think there is any need to resolve that controversy as - I believe - the action called for would be identical in either case.

1) Let's assume we all disliked flatpak. Then we'd not make a flatpak template. In cases where linking to a flatpak would be warranted, one would just use the already available link option, e.g. "[Nextcould](http://flathead/whatever.stuff)"

2) Or let's assume we all loved flatpak and wanted to insert them wherever we could in our wiki. We'd still not have any use for a template, as each flatpack would need a name, and a url to where it could be retrieved. So at best, we might change the above syntax to "{Nextcloud|http://flathead/whatever.stuff}". That really doesn't seem to warrant a template.

So my response: a template would serve no purpose whether or not we loved or hated flatpaks. So - unless my assessment of what a template could be is wrong - there's not really any need to debate the (de)merits of flatpak to resolve the present feature request.

Templates aren't magic. They don't go search the web for a potential source for a given flatpak name. They just take input parameters, and format them in a predefined way. That said, I am a firm supporter of Arthur C Clarke's view "Magic is just science we don't understand yet." If you can produce code for a template that will do what I currently see as a bit magical, then please do; that'd be awesome. Then we could discuss how useful said code would be.

EDIT: It's been a while since I worked with mediawiki - my template format is clearly wrong. It would need at least 3 parameters: 1 identifying it as a flatpak link, one the package name, and one the source. To be fair though, the template could hold a dictionary of common flatpack sources. So it might be like "{flatpak|flathub|Nextcloud}". But still that save very little typing, and no work, as the author/editor of the wiki page would still have to go find Nextcloud on one of the flatpack supplier sites. Once found, it seems at least as easy to just use the link to that page as to type it up in a template format.

So in otherwords, I see the current issue as:

if (is_flatpak_good())
   use_link();
else
   use_link();

Any good compiler would optimize away the call to "is_flatpak_good" and never execute that function. And if we persist in speculative execution of the is_flatpak_good function in this thread, I might just have a MELTDOWN

Last edited by Trilby (2018-01-26 14:37:55)

NeoTheFox · 2018-01-26 14:45:33

Oh, thanks for looking into it, Trilby. I am no good with mediawiki either, and the way I would've done it right now is:
{{Flatpak|org.company.Name}} so it would resolve as: Name(link to flatpakref)^Flatpak(link to flatpak article). I am playing around with implementing it right now in sandbox, still trying to figure out how to discard everything before the last dot.

eschwartz · 2018-01-26 15:02:31

NeoTheFox wrote:

[...] I am not trying to claim that flatpak is silver bullet. However as an option I think it deserves inclusion into some wiki articles, and a template would archive this goal.

My main problem is not, in fact, flatpak itself. It is this addendum, which is really unrelated to the question of templates at all:

NeoTheFox wrote:

How I suggest using flatpak template:
1) Prioritize repo packages over flatpak, but flatpak over AUR by order
2) Stress that Flatpak packages are unsupported

As for flatpaks themselves, I regard them as probably the least broken of all Windows-style upstream binary tree collections. But cf. this discussion founded by Trilby.

Last edited by eschwartz (2018-01-26 15:03:36)

NeoTheFox · 2018-01-26 15:10:02

Eschwartz wrote:

NeoTheFox wrote:
[...] I am not trying to claim that flatpak is silver bullet. However as an option I think it deserves inclusion into some wiki articles, and a template would archive this goal.
My main problem is not, in fact, flatpak itself. It is this addendum, which is really unrelated to the question of templates at all:
NeoTheFox wrote:
How I suggest using flatpak template:
1) Prioritize repo packages over flatpak, but flatpak over AUR by order
2) Stress that Flatpak packages are unsupported
As for flatpaks themselves, I regard them as probably the least broken of all Windows-style upstream binary tree collections. But cf. this discussion founded by Trilby.

I don't think that calling it "Windows-style" is far, Windows-style is what GOG does with their .sh installers. This is much more in line with Android-style. But yeah, I fully agree that all these formats - snaps, flatpaks, and worst of all - App Images are not as good as packages. However regardless of if we like it or not it's happening due to demand for such distribution formats, and if we wouldn't help our favorite horse in this race the worse formats would win. Compared to Flatpak, AppImage is a security nightmare that had been gaining traction lately, so backing flatpak just makes more sense, as it is also doesn't have hard coded sources and mandatory codes of conduct as Snap does. The reason why I suggested Flatpak over AUR in priority ladder is effort required to use AUR vs effort required to use Flatpak from the user, of course it's up for debate. People who know how to use AUR and do so willingly would still use AUR, but if you recommend AUR to someone who doesn't read PKGBUILDS and prefers using AUR helper with signature checking off I don't see much benefits over Flatpak in such case.

Trilby · 2018-01-26 15:23:07

Why back the least bad of bad horses at all when there are perfectly good horses to go with; just don't get on the high ones, don't beat the dead ones, and don't look in the mouths of ones that are gifts.

eschwartz · 2018-01-26 15:36:56

NeoTheFox wrote:

[...] Compared to Flatpak, AppImage is a security nightmare that had been gaining traction lately [...]

Irrelevant, repository packages are the same "security nightmare" so stop conflating flatpak as a way to more easily install large, complex software with flatpak as a security model.

NeoTheFox wrote:

The reason why I suggested Flatpak over AUR in priority ladder is effort required to use AUR vs effort required to use Flatpak from the user, of course it's up for debate. People who know how to use AUR and do so willingly would still use AUR, but if you recommend AUR to someone who doesn't read PKGBUILDS and prefers using AUR helper with signature checking off I don't see much benefits over Flatpak in such case.

It is very much up for debate, and once again you are arbitrarily injecting the foreign idea of package formats as a security model.

NeoTheFox · 2018-01-26 19:01:25

Eschwartz wrote:

It is very much up for debate, and once again you are arbitrarily injecting the foreign idea of package formats as a security model.

In this case Flatpak is not just a package format, but also a software product that has sandboxing as one of its features. Isn't reasonable to take that feature into account when talking about Flatpak?

I've made a template, so it's up for review now. Ideally it would check other things besides flathub but the beauty of templates is that they always can be updated all at once.

Trilby · 2018-01-26 19:30:24

Yes, you've created a template. But does it work? I didn't think you provided an example. I wondered how it could work, so I checked the source. You *do* have an example there but it doesn't work: nothing shows up. No link. Nothing.

Last edited by Trilby (2018-01-26 19:30:58)

lahwaacz · 2018-01-26 19:54:53

Obviously the Arch wiki promotes the way Arch developers and TUs prefer to distribute the software for Arch. There is not much place for anything else, regardless of what's the distribution method preferred by upstream - they should have their own documentation if the traditional packaging is problematic. For example, Python packages are commonly distributed via the Python Package Index and pip is the tool for installation of the packages recommended by the Python community, but that does not mean that every PyPI package should be listed on our wiki.

Here is how the template preference for packages works:

1. If there is a package in the official repositories, it is linked with Template:Pkg. If there is a modified package elsewhere, e.g. in the AUR, it can be linked as well, but usually nothing else (not even development packages in AUR) is linked.
2. If the package exists in the AUR, it is linked with Template:AUR instead of Template:Pkg.
3. If the package does not exist even in AUR, then provide whatever installation method works - but it will be deleted as soon as an AUR package appears. Or, preferably, link to upstream documentation.

Hence, providing Flatpak links as an alternative to official or AUR packages is not possible. The experience with PyPI clearly leads to the conclusion that no template is needed for case 3. I'll archive your template, sorry.

I also dislike your intention to "promote flatpak usage among ArchLinux users" this way. If you want that, go talk to the devs.

Last edited by lahwaacz (2018-01-26 19:56:29)

Arch Linux

#1 2018-01-26 12:57:28

[Wiki] Add a template for Flatpak packages

#2 2018-01-26 13:13:38

Re: [Wiki] Add a template for Flatpak packages

#3 2018-01-26 13:17:05

Re: [Wiki] Add a template for Flatpak packages

#4 2018-01-26 13:19:50

Re: [Wiki] Add a template for Flatpak packages

#5 2018-01-26 13:26:16

Re: [Wiki] Add a template for Flatpak packages

#6 2018-01-26 13:30:10

Re: [Wiki] Add a template for Flatpak packages

#7 2018-01-26 13:47:31

Re: [Wiki] Add a template for Flatpak packages

#8 2018-01-26 14:05:04

Re: [Wiki] Add a template for Flatpak packages

#9 2018-01-26 14:45:33

Re: [Wiki] Add a template for Flatpak packages

#10 2018-01-26 15:02:31

Re: [Wiki] Add a template for Flatpak packages

#11 2018-01-26 15:10:02

Re: [Wiki] Add a template for Flatpak packages

#12 2018-01-26 15:23:07

Re: [Wiki] Add a template for Flatpak packages

#13 2018-01-26 15:36:56

Re: [Wiki] Add a template for Flatpak packages

#14 2018-01-26 19:01:25

Re: [Wiki] Add a template for Flatpak packages

#15 2018-01-26 19:30:24

Re: [Wiki] Add a template for Flatpak packages

#16 2018-01-26 19:54:53

Re: [Wiki] Add a template for Flatpak packages

Board footer