Meanwhile almost evergything I ever wanted is either in main Gentoo repo or in there is overlay with it.
Honestly, main + guru has not made feel like anything’s missing at all.
Main + kdab + steam
I am inclined to write “Main +” and then just some random words, to see if you guys could tell they’re not repos. 🙃
Guru is Project:GURU, kdab is KDAB overlay for hotspot profiler and steam is steam-overlay
Sure, but through your link, I found the list of projects. In hopes that a project always has a repo associated, here comes the quiz: Can you guess which 2 of these projects I made up? 🙃
Main + Artwork + Astronomy + Biology + Chemistry + Electronics + Geosciences + Mathematics + Physics + Psychology + Science + Retirement + Emacs + GNU Emacs + Spacemacs + XEmacs
I did expect there to be lots of random words, but man, I seriously had to think for a moment to find a field of science that isn’t covered…
I seriously had to think for a moment to find a field of science that isn’t covered…
And you choose phsycology… Medicine would be less obvious.
For my second guess I was choosing between retirement and spacemacs. As it turns out, Project:Retirement is a thing.
Also Project:Main doesn’t exist. So you made up 3 projects.
That list I and person I replied to posted was list of overlays.
Welp. I didn’t want to make it too difficult either, especially with how funky some of the real projects are. Would be cool, though, if more psychology software existed. Surely, there’s a lot you could do with video games / simulations.
They do? I’ve always seen that as being up to distro maintainers, and out of control of the devs.
Bottle’s developers disagree with this meme
I cannot use bottles since months due to their faltpak monogamy policy :/
…explain? It literally has Flatpak as first-class support, i.e. it’s guaranteed and only guaranteed to work on Flatpak
Because I use it from the AUR…
I like Flatpak just because it isn’t Snap
The enemy of my enemy, eh?
…is my enemy’s enemy, no more, no less. (Maxims of Maximally Effective Mercenaries #29)
Fair. Also, flatpak does not try to break everything by default, which is a plus.
Are those flatpak haters that say that in the room with us right now? The main difference with distro repos is that packages in it are packaged by the distro packagers and everyone who has an opinion on flatpak should know that this is how it works.
The main difference with distro repos is that packages in it are packaged by the distro
Uh… Yes? That’s what the meme says?
False, if it exists in the Linux ecosystem it also exists in AUR
The broader meta point is that X thing you want isn’t the devs job, btw.
X thing you want isn’t the devs job
Well, it is if they decide it is, and it isn’t if they decide it isn’t.
That said, I do appreciate devs who put up native deb or rpm repos for the most common distros.
Flatpak is nice but I really would like to see a way to run flatpakked application transparently e.g. don’t have to
flatpak run org.gnome.Lollypopand can just run the app via
LollypopYou could make aliases for each program, but I agree, there should be a way to set it up so they resolve automatically.
You could possibly also make a shell script that does this automatically. I believe most flatpak ids follow a pattern such as com.github.user.package, for github projects for example. So you could loop through all installed flatpaks, extract the name, and then add the alias.
Agreed, but I also feel like such a thing should be included with Flatpak by default instead of leaving it to the users to solve.
You can symlink
/var/lib/flatpak/exports/bin/org.gnome.Lollypop(if you are using a system installation) or~/.local/share/flatpak/exports/bin/org.gnome.Lollypop(if you are using a uset installation) to~/.local/bin/lollypopand run it aslollypop.I just run them raw, like just
org.gnome.Lollypop
Not ideal, but it’s what I do
It’s fecking raw!
[Honk Honk]
Sewer Count: 999
Nice fucking model! #FreeCivvie11
put flatpak in your PATH and you can youse the app name like normal
Well, Flatpak installs aliases, so as long as your distribution - or yourself - add the
<installation>/exports/binpath to$PATH, then you’ll be able to use the application IDs to launch them.And if you want to have the Flatpak available under a different name than its ID, you can always symlink the exported bin to whatever name you’d personally prefer.
I’ve got Blender set up that way myself, with theorg.blender.Blenderbin symlinked to/usr/local/bin/blender, so that some older applications that expect to be able to simply interop with it are able to.Is there some way to set an install hook that automatically makes those symlinks when you install a flatpak?
I’m a Debian fan, and even I think it’s absolutely preferable that app developers publish a Flatpak over the mildly janky mess of adding a new APT source. (It used to be simple and beautiful, just stick a new file in APT sources. Now Debian insists we add the GPG keys manually. Like cavemen.)
And then change where we put them.
Someone got to say it…
There is no Debian if everything was a pile of Snaps/Flatpack/Docker/etc. Debian is the packaging and process that packaging is put through. Plus their FOSS guidelines.
So sure, if it’s something new and dev’y, it should isolate the dependencies mess. But when it’s mature, sort out the dependencies and get it into Debian, and thus all downstream of it.
I don’t want to go back to app-folders. They end up with a missmash of duplicate old or whacky lib. It’s bloaty, insecure and messy. Gift wrapping the mess in containers and VM, mitigates some of security issues, but brings more bloat and other issues.
I love FOSS package management. All the dependencies, in a database, with source and build dependencies. All building so there is one copy of a lib. All updating together. It’s like an OS ecosystem utopia. It doesn’t get the appreciation it should.
Now Debian insists we add the GPG keys manually. Like cavemen.)
Erm. Would you rather have debian auto-trust a bunch of third party people? It’s up to the user to decide whose keys they want on their system and whose packages they would accept if signed by what key.
Not “auto trust”, of course, but rather make adding keys is a bit smoother. As in “OK, there’s this key on the web site with this weird short hex cookie. Enter this simple command to add the key. Make sure signature it spits out is the same on the web page. If it matches, hit Yes.”
And maybe this could be baked somehow to the whole APT source adding process. “To add the source to APT, use
apt-source-addinate https://deb.example.com/thingamabob.apt. Make sure the key displayed is0x123456789ABCbyThingamabob Teamwith received key signature0xCBA9876654321.”
If I can choose between flatpack and distro package, distro wins hands down.
If the choice then is flatpack vs compile your own, I think I’ll generally compile it, but it depends on the circumstances.
I change my opinion depending on which app it is. I use KDE, so any KDE app will be installed natively for sure for perfect integration. Stuff like grub costumizer etc all native. Steam, Lutris, GIMP, Discord, chrome, firefox, telegram? Flatpak, all of those. They don’t need perfect integration and I prefer the stability, easy upgrades and ease of uninstall of flatpak. Native is used when OS integration is a must. Flatpak for everything else. Especially since sometimes the distro’s package is months/years old… prefering distro packages for everything should be a thing of the past.
I’m 100% on this camp.
Why?
Stubbornness
Based
Because it’s easier to use the version that’s in the distro, and why do I need an extra set of libraries filling up my disk.
I see flatpack as a last resort, where I trade disk space for convenience, because you end up with a whole OS worth of flatpack dependencies (10+ GB) on your disk after a few upgrade cycles.
Is compiling it yourself with the time and effort that it costs worth more than a few GB of disk space?
Then your disk is very expensive and your labor very cheap.
For a lot of project “compiling yourself”, while obviously more involved than running some magic install command, is really not that tedious. Good projects have decent documentation in that regard and usually streamline everything down to a few things to configure and be done with it.
What’s aggravating is projects that explicitly go out of their way to make building them difficult, removing existing documentation and helper tools and replacing them with “use whatever we decided to use”. I hate these.
I should have noted that I’ll compile myself when we are talking about something that should run as a service on a server.
They didn’t say anything about compiling it themselves, just that they prefer native packages to flatpak
2 comments up they said
If the choice then is flatpack vs compile your own, I think I’ll generally compile it, but it depends on the circumstances.
99% of the time it’s just “make && sudo make install” or something like that. Anything bigger or more complicated typically has a native package anyway.
TEN WHOLE GIGABYTES!! OMG WHAT ARE WE TO DO??
10 out of 40 is 25%
10 out of 4000 is 0.25%
I mean it’s 2024. I regularly download archives that are several tens or even over 100 GB and then completely forget they’re sitting on my drive, because I don’t notice it when the drive is 10TB. Last time I cared about 10GB here and there was in the late-2000s.
Great that you have 4tb on your root partition then by all means use flatpack.
I have 256Gb on my laptop, as I recall I provisioned about 40-50gigs to root.
Why not upgrade your hdd?
I’m sorry. I didn’t realize people were still regularly using such constrained systems.
🤣
flatpak has dedub, so no
Yep that’s all well and good, but what flatpack doesn’t do automatically is clean up unused libs/dependencies, over time you end up with several versions of the same libs. When the apps are upgraded they get the latest version of their dependency and leave the old behind.
And this, this is why I love the AUR
I think no one said it needs to be ON a distro’s repos. That’s a straw man.
A package should be available in a native package format in a way that doesn’t cause conflict with what’s in the official repo.
Wow, is this meme a really naive take that is contradicted by - oh god, everything. Can someone know about enterprise Linux and also be this naive?
The responsibility to figure out the dependencies and packaging for distros, and then maintain those going forwards, should not be placed on the developer. If a developer wants to do that, then that’s fine - but if a developer just wants to provide source with solid build instructions, and then provide a flatpak, maybe an appimage, then that’s also perfectly fine.
In a sense, developers shouldn’t even be trusted to manage packaging for distributions - it’s usually not their area of expertise, maintainers of specific distributions will usually know better.
While I agree that developers (like myself) are not necessarily experts at packaging stuff, to conclude that it’s fine that a developer provides a flatpak is promoting shitty software. Whether a software should run in a jail, or within user space is a decision that - for most use cases - should be made by the user.
There is absolutely no reason not to provide software as a tar.gz source code archive with a proper makefile & documentation of dependencies - or automake configuration if that’s preferred.
From that kind of delivery, any package maintainer can easily build a distro-package.
I think you’re actually agreeing with me here. I was disputing the claim that software should be made available in “a native package format”, and my counterpoint is that devs shouldn’t be packaging things for distros, and instead providing source code with build instructions, alongside whatever builds they can comfortably provide - primarily flatpak and appimage, in my example.
I don’t use flatpak, and I prefer to use packages with my distro’s package manager, but I definitely can’t expect every package to be available in that format. Flatpak and appimage, to my knowledge, are designed to be distro-agnostic and easily distributed by the software developer, so they’re probably the best options - flatpak better for long-term use, appimage usable for quickly trying out software or one-off utilities.
As for tar.gz, these days software tends to be made available on GitHub and similar platforms, where you can fetch the source from git by commit, and releases also have autogenerated source downloads. Makefiles/automake isn’t a reasonable expectation these days, with a plethora of languages and build toolchains, but good, clear instructions are definitely something to include.
Makefiles/automake isn’t a reasonable expectation these days, with a plethora of languages and build toolchains, but good, clear instructions are definitely something to include.
As for the Makefiles, I meant that for whatever build toolchain the project uses - because the rules to build a project are an essential part of the project, linking the source code into a working library or executable. Whether it is cmake, or gnu make, or whatever else there is - that’s not so important as long as those build toolchains are available cross platforms.
I think what is really missing in the open source world is a distribution-agnostic standard how to describe application dependencies so that package maintainers can auto-generate distro-packages with the distribution-specific dependencies based on that “dependencies” file.
Similar to debian dependencies
Depends: libstdc++6 (>= 10.2.1)but in a way that identifies code modules, not packages, so that distributions that package software together differently will still be able to identyfindPackageFor( dependency )I would really like to add this kind of info to my projects and have a tool that can auto-build a repo-package from those.
“oh this is a flatpak or hell even a windows exe…” proceeds to search for it on AUR “ah there it is, wonderful!”
Hell I’ve found a god damn windows gaming cheat trainer on AUR and it worked.
The AUR is basically just a script that describes best case scenario for building something under Arch. They don’t have any specific quality rules they have to meet.
It’s super easy to make and publish an AUR script compared to a regular distro package (including Arch packages).
I’m new to Linux. Every time I’ve had a major issue with an application it turned out to be due to a flatpak. I’ll stick with other options for the time being.
Also at least let me compile it myself if not in a repo 😩
If you’re separating your application from the core system package manager and shared libraries, there had better be a good and specific reason for it (e.g. the app needs to be containerized for stability/security/weird dependency). If an app can’t be centrally managed I don’t want it on my system, with grudging exceptions.
Chocolatey has even made this possible in Windows, and lately for my Windows environments if I can’t install an application through chocolatey then I’ll try to find an alternative that I can. Package managers are absolutely superior to independent application installs.
I think containerization for security is a damn good reason for virtually all software.
emerge sec-policy/selinux-*
Definitely. I’d rather have a “good and specific reason” why your application needs to use my shared libraries or have acess to my entire filesystem by default.
Using your shared libraries is always a good thing, no? Like your distro’s packages should always have the latest security fixes and such, while flatpaks require a separate upgrade path.
Access to your entire filesystem, however, I agree with you on.
I only use rolling releases on my desktop and have ran into enough issues with apps not working because of changes made in library updates that I’d rather they just include whatever version they’re targeting at this point. Sure, that might mean they’re using a less secure version, and they’re less incentivized to stay on the latest version and fix those issues as they arise, but I’m also not as concerned about the security implications of that because everything is running as my unprivileged user and confined to the flatpak.
I’d rather have a less secure flatpak then need to downgrade a library to make one app I need work and then have a less secure system overall.
Flatpack can be centrally managed, it’s just like a parallel distribution scheme, where apps have dependencies and are centrally updated. If a flatpack is made reasonably, then it gets library updates independent of the app developer doing it.
“App image” and " install from tarball" violate those principles, but not snap or flatpack.
Um, if it’s “parallel” (e.g. separate from the OS package manager) then it’s not centrally managed. The OS package manager is the central management.
There might be specific use cases where this makes sense, but frankly if segregating an app from the OS is a requirement then it should be fully containerized with something like Docker, or run in an independent VM.
If a flatpack is made reasonably, then it gets library updates independent of the app developer doing it.
That feels like a load-bearing “if”. I never have to worry about this with the package manager.
Define “the OS package manager”. If the distro comes with flatpack and dnf equally, and both are invoked by the generic “get updates” tooling, then both could count as “the” update manager. They both check all apps for updates.
Odd to advocate for docker containers, they always have the app provider also on the hook for all dependencies because they always are inherently bundled. If a library has a critical bug fix, then your docker like containers will be stuck without the fix until the app provider gets around to fixing it, and app providers are highly unreliable on docker hub. Besides, update discipline among docker/podman users is generally atrocious, and given the relatively tedious nature of following updates with that ecosystem, I am not surprised. Even best case, docker style uses more disk space and more memory than any other option, apart from VM.
With respect to never having to worry about bundled dependencies with rpm/deb, third party packages bundle or statically link all the time. If they don’t, then they sometimes overwrite the OS provided dependency with an incompatible one that breaks OS packages, if the dependency is obscure enough for them not to notice other usage.
I’m not sure where you’re getting the idea that Flatpak aren’t centrally managed…
Can I
sudo apt upgrademy installed flatpak apps?No, because they’re not apt packages. You can, however,
flatpak updatethem, and you don’t even need sudo since they’re installed in the user context rather than system.
Typically Windows applications bundle all their dependencies, so Chocolatey, WinGet and Scoop are all more like installing a Flatpak or AppImage than a package from a distro’s system package manager. They’re all listed in one place, yes, but so’s everything on FlatHub.
This is true, the only shared libraries are usually the .NET versions, but so many apps depend on specific .NET versions that frequently the modularity doesn’t matter.
I think stability is a pretty good reason
If an app can’t be centrally managed
Open Discover, Gnome Software etc -> Click update?
flatpak upgradeAnd with topgrade you can even upgrade flatpaks and your distros repos in one go
I’m now confused if they’re saying that flatpak is centrally managed or not. To me it seems centrally managed, both the flatpak ecosystem but your whole machine (repo packages, firmware, flatpak) if you use those app stores. I might’ve misunderstood what they said.
We’re both saying that it’s centrally managed
Oh no, no GUI nonsense. Single, simple shell command update for the whole system so that it can be properly remotely managed, please. Something equivalent to
sudo apt upgrade
I don’t wanna be that guy, but someone has to say it: Nix Flakes
I have both nix and flatpak lol. Different usecases: flatpak for stuff that I would rather have sandboxed (browsers, games), nix for stuff that I would rather be integrated into the system (command line tools, etc). Tho I still have to learn about flakes, right now I’m just using
nix-envfor everything like a caveman lol
Flatpak haters hate new apps anyway.
glibc 2.36 is all you’ll ever need, okay? Go away with those goddamn backports!
