You don’t need the distro to package your sodtware through their package management systems though. Apt and dnf repositories are extensible, anyone can publish. If you go to copr or ppa you can have a little extra help too, without distro maintainers.
The headache comes up when multiple third party repositories start conflicting with each other when you add enough of them, despite they’re best efforts. This scenario starts needing flatpack, which can, for example concurrently provide multiple distinct library versions installed that traditionally would conflict with each other. This doesn’t mean application has to bundle the dependency, that dependency can still be external to the package and independently updated, it just means conflicts can be gracefully handled.
The headache comes up when multiple third party repositories start conflicting with each other
Which is traditionally why you needed the distro to package your software…
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…
Just compile from source?
This doesn’t scale. If I have a bug and my package has about two dozen dependencies which can all be different versions, and the developer can’t reproduce my bug, I’m just screwed. Developers don’t have the time and resources to chase down a bug that depends on build time variables.
Ask me how I know this happens.
Not optimal
Yes, it would depend on your flatpack usage. For me I only have like 5 programs compiled from source and one flatpack (bottles) because of the sandboxing
That’s not good. It breaks the system as there isn’t any change control with that unless your using something like Gentoo. Get your packages from the package manager.
I like the ports tree that only compiles from source, yes it’s slow, but you know the binaries you make are pure.
Because it’s always so easy to compile everything you need from source! Just make sure to download, compile and install the dependencies first as well. Oh, and the dependencies’ dependencies. And the ones from them. And so on. Unless you’re lucky enough that there are already packaged dependencies available for you. Don’t know how to compile? No problem, just read the documentation. You can be absolutely 1000000% dead serious sure that everything you need to know is documented and extremely super duper easy to understand if you don’t know the source code or barely know how to code at all. And if not, maybe you can find the bits of information on the respective Discord server. It will probably be also very intuitive to know which build options you have to set in which way and which ones even exist. And that without causing conflicts with other packages you need to compile. Still got got problems with compiling? EZ, just open a bunch of issues on the respective GitHub pages. (If present. Otherwise, try to find another way to contact devs and get support, Discord for example.) Maybe, about six months later you’re lucky to get a response. And if not, don’t worry. Some will tell you, you should RTFM or are an idiot. Some will just close the issue because your platform isn’t supported anyway. Then you know, what you did wrong. Also don’t mind if your issue gets ignored.
If you finally managed to compile everything from source, congratulations! Now run the program and test if everything is working. If it’s not or if it is crashing, don’t worry! In developed and civilised countries you can just buy a shotgun and blast your own head away to end this suffering.EZ! Just compile from source! /s
My workflow always definitely includes multiple weeks to debug random issues with building the tools I need to use. Totally a scalable and good solution to dump this work on the end user.
I just complie from source some lightweight programs that are too niche for repositories. I am in no way advocating for full source compilation of every program in your system, that’s a security and usage nightmare. Flatpack does have its use for sandboxing an environment. I personally use it for windows applications in bottles.
You have rediscovered LFS
Back in the day, when I installed my very first Linux OS, I had a wireless stick from Netgear. Wireless Drivers back then were abysmal, so I had to compile them from source (literally 15 mins after seeing a TTY for the first time). After I had found out how build-dependencies and such worked somehow and ./configure completed successfully for the first time, the script ended with the epic line:
configure done. Now type 'make' and prayAh, I had one of those wireless sticks from Netgear as well, probably a different model but still a royal pain to get it working.
Luckily ndiswrapper has become a thing of the past nowadays.
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 like Flatpak just because it isn’t Snap
Fair. Also, flatpak does not try to break everything by default, which is a plus.
The enemy of my enemy, eh?
…is my enemy’s enemy, no more, no less. (Maxims of Maximally Effective Mercenaries #29)
I know nothing about how flatpak works other than that it’s containerized. But this meme tells me it’s the OS’s responsibility to create the flatpak, and not the developer’s? Is that right?
No the most common way is for devs to package their own software as a flatpak since you can typically choose your preferred packaging tool to use inside of the flatpak.
Traditional package management typically is done by the distro maintainers.
Oh I see, I’ve got it backwards.
I’ve never used it. Its like all the others though and I have been forced to use snaps. Those I slowly replace every time I decide to start fresh.
Try linux mint, it’s basically ubuntu but without snap (you can install snap if you want to, but it’s not forced on you)
Oh I have. I have it running on some older hardware.
Haters aren’t worth listening to. Doesn’t matter if it is flatpak, systemd, wayland, or whatever else. These people have no interest in a discussion about merits and drawbacks of a given solution. They just want to be angry about something.
I know, right!? Add gimp to that list as well. I can go on and on about shortcomings of gimp despite being a happy user. The average gimp hater, on the other hand, doesn’t have anything to say besides “the UI is dumb and I can’t figure out how to draw a circle”
“The UI is unintuitive” is a legitimate complaint
“Intuitive UI” results in Gnome.
Is it really intuitive if I have to open dconf-editor to change the system font?
They call it “intuitive UI”, Linus calls it “‘users are idiots, and are confused by functionality’ mentality of Gnome”
It’s not always a zero-sum game.
Elaborate? Most of good UI comes from KDE.
What I mean is, makingg a UI more intuitive does not necessarily make it more… Gnome-ey? It can still be effective, customizable, etc.
“Intuitive UI” crowd usually means Gnome-ey/Apple-ey design.
In reality customizable design is more intuitive, because you can customize it to your intuition.
Wayland gets the hate because compositors are authoritative so you cannot e.g. install your own window manager, taskbar, etc. It would be good if there were specifications governing these, but there isn’t.
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
Laughs in AUR
Laughs in nixpkgs
Laughs in confusion
(I dont know how i got here)
Laughs in support
Support laughs in you
Cracks up in ebuilds
Snickers in pipx
Not great to laugh at the mess Linux is in, due to people paddling in different, incompatible, directions. Users can’t choose the package format. They have to take what they are given. Good or bad. I don’t care which format. As long as it works. But this is a good way to scare more people off of Linux.
laughs at people scared of choice and “mess” . . .
If they’re switcing to linux they should first come to know about open source forking around - arguably - one of the most important features of the whole thing.
If they don’t wan’t that choice and all that inevitable open source forkery, they probably should go for an apple mac or windows or something like that. And maybe they will have to pay for some software for the privilege because it takes work to do those things. They can of course try plain old ubuntu and do stuff the way canonical wants, that removes quite a bit of choice if it is otherwise too terrifying for them.
But in general, I don’t think its a good idea to to try to sell pig-carcasses to vegans by painting them the colours of broccoli.
I like the aur too but a proprietary app that isn’t updated to support newer dependencies, it most likely won’t run anyway. At that point it’s either broken app, broken system, or you don’t have anything else installed using that library(yet).
Not an issue on NixOS, you can ship old deps with it
Lol who the fuck is blaming app devs? Also something something arch
…btw
aur is the only thing I miss. I do like fedora with i3 very much but rpm can be pain in the ass sometimes
distrobox?, i also installed nix and works perfectly
could you perhaps run them with Distrobox? i was always wondering that.
Yes! This is something I do on 3 of my machines. My ArchLinux Distrobox with paru works like a charm. (so far)
that’s very good to hear, I’ll probably try out silverblue with distrobox and that’ll be my end of distrohopping
It was for me, check out ublue for simpler setup.
most likely but I’m super lazy with my pc unless I’m having hyperfocus going, so I don’t know
If you really hate flatpak just make an arch distrobox and download off the AUR. Or install Nix or something
Or just use Arch… only for half of your AUR packages to be broken and end up still using flatpaks anyways.
I do sort of wish Nix was a more popular distro agnostic solution
That’s what I’ve done with my deck. Some things just aren’t available through discover, and the Firefox build on there has behavior that I don’t like or know how to correct. Distrobox gives me access to the Arch repos + AUR with persistence that you can’t get on SteamOS without it.
SteamOS is an arch derivative, so you could also just install arch, add the SteamOS repos, and set the steam UI in gamescope to launch on login
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.
laughs in appimage.
They do? I’ve always seen that as being up to distro maintainers, and out of control of the devs.
