So if I installed the software from source you wouldn’t have a problem with it?
I can give it a try though just to see how the experience is as a comparison, as of late I’ve seen a lot of people Lutris and Steam break having installed in through the repos.
It’s your computer, not mine. I don’t have a problem if you spill water into the PSU. That would be your problem, not mine.
I’m just saying, for the benefit of anyone else reading this who is unsure, that the best practice for installing software is to use the package manager that your distribution supplies you with.
As far as “installing the software from source”, I’m not sure what you mean. If you mean compiling it from source code locally, that is not the same as installing it. In that case then the best practice is either to build it locally and keep it in your user’s directory. Or build it as a ALPM package using makepkg (basically, write your own PKGBUILD) and install it with pacman. Ideally, you should never manually add files to the /bin or /usr/bin directories.
Or in /usr/local if you want to install it system-wide if you have more than user on your system but yeah that’s what I meant.
AUR helpers aren’t supported as mentioned in the Archwiki, is it then also bad(or not best) practice to use an AUR helper to install a PKGBUILD from the AUR and all of it’s dependencies?
I’ll remove my Flatpaks for Steam and Lutris and install the ones from the repos including their libraries and then see how the experience 
If something breaks, I’ll know where to find you 
j/k
It’s certainly a very good practice to be capable of using the AUR without an AUR helper, yes. That gives you an understanding of what an AUR helper does, how the package building process works on Arch Linux. This is how the AUR was designed to be used. Now, an AUR helper helps to automate most of the manual work required, but an AUR helper shouldn’t be something you depend on.
local/steam 1.0.0.78-1
Valve's digital software delivery system
local/lutris 0.5.13-5
Open Gaming Platform
Happy now?
I was happy even before you did that (in small part due to not using any flatpaks myself). The question is, are you happy? I hope you are.
I know i am happy!
I’m giving it a chance to see how the experience now is, even though I’ve read a lot of breakages with the normal Steam and Lutris packages lately. So time will tell if I am happy.
I don’t use Steam (or any soyftware that requires subscriptions and constant internet access to work), so I can’t say anything about that, but Lutris works fine on my end: it’s very rare that I have any problems with it.
Installing software from an untrusted source could be considered a bad practice though.
The lutris flatpak is official. However, the steam flatpak is published by a separate individual.
That being said, it is your machine, feel free to manage however you want. 
From what I remember reading about Flathub is that there is a submission process.
And they recently added way for packages to verify their apps.
If you look a couple replies up, I decided I would give the normal packages a try to see what the experience is like, even though I have seen quite a few posts of the Steam package breaking in the past couple weeks and also some posts about Lutris but not as frequent as the Steam breakages.
How does that help in this case? I doubt they are reviewing every commit after the submission.
Sure, but the Steam flatpak is unofficial and packaged by a separate individual so it won’t be verified.
Yeah sure, I remember reading somewhere that someone who maintains a lot Arch packages doesn’t manually review them either but built a pipeline to do it automatically, in that case the person is not reviewing every commit themselves either but a script is doing it.
In the end is matter of trust. My point was I just dislike having 32 bit libraries installed and seeing them in my package output, that’s why I had them running in a container because then they were out of sight. I would be really happy if they figured out a way to run 32 bit applications without having to install 32 bit libraries on a 64 bit system.
That is totally different. That is about reviewing the upstream changes. i.e. In this case “Do I trust Steam”.
This is about trusting the packager. Since the packager is, from my perspective, a random individual who decided to package Steam. Since I don’t know that person or their reputation, I don’t trust that package.
No flatpaks …definitely no snaps or app images. It’s AUR all the way. Or no way!
In the end @Kresimir convinced me to try out the Steam and Lutris packages from the repos and to install the 32 bit libs needed for them. I will just have to see how the experience is, knowing I have seen more posts about Steam having broken these last few weeks and posts about people having issues with Lutris but not on the Flatpak version of Lutris. I now have zero Flatpaks installed.
THis is a slightly problematic title asking about ‘Best Practice Flatpak VS AUR’.
This is simply the wrong way to look at it… Flatpak vs AUR is never going to be resolved - they are simply options and issue is about individual and specific cases.
My use-case would be for Plex-HTPC.
Recently I switched - it is officially released on Snap, and the AUR entry had it downloaded and installed very nicely.
Ricklinux is having fun - but Joplin worked well for me as an appimage a couple of years ago.
So to answer your question, Best Practice (for Plex-HTPC) is currently Flatpak, but last year it was AUR (and the official channel is snapcraft.io).
I know that, I just decided since I am on Arch might as well make use of the AUR for all packages that aren’t in the default repos. When I was on Fedora that was a different story because some packages in rpmfusion are slow with updating and the Flatpaks got faster updates. The only current AUR package that seems the be a problem because it’s flagged out date since beginning of this year.
Which package?
https://aur.archlinux.org/packages/plex-desktop
I have it installed but not the most recent version but it still works, I hope the maintainer is able to fix the problem they are having with getting it working with a more recent build from the official snap they are using.