I was happy to do it. ![]()
I think what should also be considered:
Runtimes
Runtimes provide the basic dependencies used by applications. Each application must be built against a runtime, and this runtime must be installed on the host system for the application to run. (Flatpak can automatically install the required runtime for an application.) Multiple runtimes and different versions of the same runtime can be installed alongside each other.
Runtimes are distribution agnostic and do not depend on a particular distribution version. This means that they provide a stable, cross-distribution base for applications and allow applications to work irrespective of operating system updates.
Bundled libraries
If an application requires dependencies that arenāt in its runtime, they can be bundled with the application. This gives application developers flexibility in their choice of dependencies, allowing them to use:
libraries that arenāt available in a runtime
different versions of libraries from those available in a runtime
patched versions of libraries
Dependencies as such are not necessarily up-to-date. Beware in case! (It depends strongly on the maintainer of a packageā¦)
Regarding your OP, I canāt (and wonāt) argue the security concerns that can arise from using things like software.opensuse.org and opi. I think that newbies and novices alike could learn a lot from your post and may very well want to pay close attention to your advice. However, intermediate to seasoned Linux/openSUSE users may be quite comfortable accepting any possible risk by using the repos of their choice, as I do.
Iāve been an Arch user for well over a decade, and an on-and-off Tumbleweed user since just before the pandemic. Iāve been using EndeavourOS (Arch-Based) on my main PC since 2021. I currently run openSUSE Tumbleweed on my Lenovo ThinkpPad T14. I use the AUR in Arch/Endeavour and OBS, opi, Packman in Tumbleweed. I always have. Iāve never suffered security issues or a bricked system. Any issues that arose were minor and easily dealt with. And, to be honest, I canāt remember any issues where I was concerned about security or that broke apps and/or dependencies.
I think my only problem with your OP is that it comes across as if your way is the āonly wayā and those using things like AUR or OBS/opi/Packman are wrong. Your closing statement, in particularā¦
Get over your prejudice against Flatpaks, use them and be fine.
- I have no āprejudice against flatpaks.ā If/when I use Flatpaks, itās because the Flatpak app works better than the app provided in either the official repo or a third-party repo.
Keep struggling with repos, broken packages, package conflicts, and a potentially compromised system.
- This statement assumes there will always be a āstruggleā with broken packages, package conflicts, and/or a compromised system. Thatās just not true. Is there a possible risk utilizing these third-party repos? Sure. Intermediate to seasoned users may want to accept that risk possibility.
Bottom line - Thereās absolutely nothing wrong with using third-party repos as long as you donāt use them blindly. Use your system as you want, but always be vigilant. Investigate packages/apps/repos.
The beauty of Linux⦠CHOICE.
If you are only a passer by forum user, you donāt see what high amount of issues are created by the use of 3rd party, home and devel repos. But the main helpers here know and see what high amount of issues are created by these reposā¦
And this is also the reason why we recommend NOT to use home/devel/3rd party repos. Unfortunately, those who recklessly recommend using home/devel/3rd party repos are not the same people here on the forum who help us deal with the resulting problems.
I dare to bet that Show zypper lr -d" is the most asked for in these forums.
No, I am not a āpasser by forum user.ā Lurked for a while, yes. Registered a week or so ago. I tend to use Linux forums when I need help or can offer help. Or in this case, offer an opinion. A new forum member doesnāt equal āpasser byā forum user.
Why would that matter, @knurpht? Iāve already said that I use third-party repos. Extensively, actually. For example, I use the kernel-liquorix from home:hwsnemo:kernels project. I have no problem showing the output of zypper lr -d and Iāll post that once I get home from work. Iām currently posting from my iPad.
You seem not to get the point.
As the main problems here in the forum are caused by the use of home/devel/3rd party repos, knurpht pointed out that the most common request from us permanent helpers is to show the repo list. It was not directed at you.
And unfortunately, the unexperienced users fall for the recommendation of 3rdparty/home/devel repos and do not know how to solve basic issues. That is why we are here sometimes a little bit annouyed to repaet over and over and over again: do not use them!
And the big advantage of flatpaks is in this case: you canāt get any package conflicts like you get with 3rd party/devel/home repos.
Fair enough, @hui. I simply misunderstood that. I thought @knurpht was asking to see mine. Apologies for the misunderstanding. And again, a new forum user does not equal a passerby. Am I just getting my feet wet here, for sure. I hope to be more active moving forward. And as I said, my post is nothing more than an opinion. Iām definitely not trying to make waves here.
It represents that experienced active users here have good reasons to suspect repos to play a role in issues.
I hear ya. As I said above, I completely misunderstood your post as @hui clarified for me. Again, apologies.
Flatpaks are also just community managed and donāt have any significant oversight. The sandbox is not perfect and since you typically have to start giving the flatpak access to your data, malware can still exist and do itās job. It is not a magical protection.
Secondly, OpenQAās tests focus on ādoes a snapshot boot to a user sessionā and little else. Snapshots have shipped broken packages and malware itself. OpenQA does not suddenly make the oss repo safer.
The choice between flatpak or rpm is how you want to work or what youāre most comfortable with. Flatpak might be easier if you do not want to learn basically anything, but you still have downsides there. Blindly installing anything always has a chance to screw things up, it doesnāt matter if the source was a randomly downloaded package or a randomly added repository; the problem is that youāre randomly doing things you donāt understand, not the source of a package.
One of the biggest issues is NOT inspecting the package in the $HOME user and seeing if itās linked to somewhere (perhaps another $HOME) or maybe was even just copied overā¦
Look at the version numbers, but also the release numbers. Many $HOME repos are links to other $HOME projects or development repositories.
Invariably this can lead to issues just with the revision versions (the numbers after the ā-ā ).
Say Tumbleweed has;
PackageX-1.2.3-2.5
The package it came from in the development repo has
PackageX-1.2.3-32.5
A $HOME package linked to the development repository has
PackageX-1.2.3-33.5
The above are all the same package, just different revisions. Then they start building for say Leap 16.0 and Leap 16.1 and yet potentially more issues for the opeSUSE Leap product users.
Then PackageX stops building and gets removed from Tumbleweed, then the Maintainer decides to delete from the development repo, all of a sudden links break, but the $HOME repo link will alas be broken, but will still retain the last built binary⦠Then your likely to be oblivious to this as you have already switched vendor, so Tumbleweed will ignoreā¦
And so, on and so on. Some $HOME repositories are all just ALL links to various other repositories because a $HOME user wants to just have one repository for their uses and is not concerned about other usersā¦
Using the likes of OPI without at least perusing the openSUSE Build Service to see at least where the source is coming from etc, well it can just spiral out of controlā¦
That is all still the āblindly doing something without understanding what it isā problem.
You can get the same things with snapshots if you donāt know what your doing. Develop or install a project with Python and use OSS for installing dependencies? Itās going to break at some point because the versions are not going to be locked for your project and those python modules are in OSS for a very different reason.
This happens because the user here didnāt know what they were doing and simply assumed that because their dependency was in the OSS repo that was the right thing to do.
You could have problems simply by using Tumbleweed and that is not the right tool for you because of the rapid upgrade cycle breaking other dependencies.
Iād argue that things packaged through flathub have āmoreā oversight than what you are potentially getting from a home: repository, as anything youāre getting from any random home: repository doesnāt have to pass any sort of checks before being published for users to download.
At the very least, the initial packaging of everything on flathub has been through the review process.
Packaging something in a home: repository, requires literally nothing more than registering for an openSUSE account in IDP. You donāt have to go through any sort of review to just start publishing packages. That only starts, when somebody starts submitting to ādevelā repos, and those maintainers do what review they choose to do.
They break their own requirements if the package is famous enough, Iām not inclined to trust that process.
Sure, you can do whatever you like, its your computer. And I know that youāve been around long enough, just based on posting history, to have at least some chance of making an informed decision about where you want to source your software from.
But directing ānewā users or ānon-technicalā users (I hate using that term, but I donāt know how else to describe it at the moment) to home: repositories, is basically no different than pointing them at the AUR, or COPR, or to just some random website to download binaries with a curl invocation. Theyāre not capable of making that informed choice, at a technical level. And I think thatās far more @knurpht point in the OP.
If you donāt trust the flathub administration, thatās perfectly valid, and Iāve got no problem with āexperiencedā folks advising people to not use flatpaks, if they really feel that itās a problematic software delivery mechanism, but to turn around and point them at a home: repo, just seems like a complete logical fallacy, as if itās somehow ābetterā
All my systems with desktop environments get VLC flatpack, just a no mess way⦠On my main Desktop I have handbrake as well and some others, but those are the main ones I useā¦
To see whole picture (regarding expected increased security of containers) there are just few Flatpak (and friends) exploits:
- https://blog.kimiblock.top/2026/07/01/arbitrary-code-execution-in-kde-plasma/
- https://github.com/flatpak/flatpak/security/advisories/GHSA-cc2q-qc34-jprg
So we should carefully watch situation to see if āsecurityā argument for containers will really survive reality check, especially when even regular packages could be sandboxed to some extent (AppArmor, SELinux, Landlock, seccomp, ā¦)
Iāve got nothing against Flatpak, but its end-user experience is terrible.
Starting with the command line and extending to its lack of integration with the system.
A silly example (Iām going from memory here): the default location for the Downloads folder in Telegram isnāt /home/$user/Downloads but something like /var/app/flatpak/verylong/something/123else.
Thatās unacceptable, and I can give plenty of other silly examples that are impacting the UX.
I prefer AppImages:
- they take up less space;
- they donāt leave ācrumbsā behind during installation;
- theyāre integrated with XDG folder convention;
- you can download them from the developerās website or GitHub;
- if they arenāt available, theyāre easy to create;
If you donāt want to go to too much trouble, thereās AppMan, which manages them neatly and with minimal effort.
Then thereās always the security expert who tells me they arenāt secure.
OK, thatās a price Iām willing to pay in exchange for better usability.