There's a lot of content packaged for the AUR that isn't readily available to people using less enlightened distributions.
I use Arch BTW.
Seriousposting: a lot of software just isn't packaged as deb or rpm because no one has taken the time to do it. The AUR is really fucking convenient as an end user. And yes, you should always skim AUR packages to be sure they're doing what they claim to do and aren't garbage, anyone can post anything. I have seen a lot of trash uploaded to the AUR.
Seriously, look at what the pkgbuild is doing on Arch and replicate it by hand on your distro of choice. That's all a pkgbuild is: a simple bash installation script.
AppImage and Docker has resolved a lot of that for me if its not in my distros package manager. It's my goto for the same reason of just not wanting to deal with it.
Could just be my use cases now compared to 10 years ago, but I've just found I'm rarely compiling these days on the host system. At least the configure-make-install or ninja variety. I'm sure I install a package here or there that does it in the background. Numpy comes to mind or an AUR package with Arch.
Just add trap 'echo ""${last_command}" No updates available at this time"' EXIT afterwards, in case the build fails ;) Might take a second to determine lol
Distrobox is your friend. Me, I like an immutable OS (kinoite) but I still want the AUR...
distrobox-create --name arch --image archlinux:latest
distrobox enter arch
install yay as normal
yay -S vscodium
distrobox-export --app vscodium
yay exa
distrobox-export --bin /usr/sbin/exa
exit [back to kinoite]
exa [works]
vscodium [works, has icon in application launcher]
Also great when you get some software as a deb for old Ubuntu and don't want the trouble of manually making it work on a new system. Just make an old Ubuntu distrobox.
I'm actually aware of Distrobox, but the thing I had in mind was for managing gaming wheel drivers, so I don't think it'd work on distrobox. It's not really that big of a deal honestly, I just made this meme to poke fun at it ^^'
TFW you're caught between being an average person and tech nerd wizard, just competent to copy/paste ubuntu-based install instructions in the terminal but get a headache trying to compile from source.
I use Mint, btw.
This is what always leads me back to arch. I can follow an outdated 12-step guide to installing the software in Debian or I can install it with one command from AUR.
I'm a noob, isn't every (open source) program aviable for every distribution if you compile it from source? It's all Linux in the end (i never compiled a program from source, so I don't know if it's easy at all)
Some programs may use libraries or tools specific to a distributions package manager. For example, yay, an AUR helper/pacman wrapper. You would have a very hard time getting it to work on Debian.
Other programs might only include build scripts for a distro specific build system. For example, a program might skip using a Makefile, and do everything in the Arch-specific PKGBUILD.
Generally though, most software uses a standard cross-distro (or even OS) build system. In this case, compiling from source would be an option on any distro. The program might still only be packaged for Arch/NixOS/Gentoo (or others), as it is a very simple process to do so.
Usually the only tricky part of compiling from source is tracking down dependencies. The package manager does that for you normally but you're not using the package manager when compiling from scratch. The actual building (even compiling a kernel) isn't all that complicated.
If you need the python header files, depending on your distro, you may need to install python3-dev, python3-devel, python3, or some other variation on the name. For a novice, this might not always be obvious and they might not know things like apt-file are helpful for figuring it out.
fr though why is the AUR specific to Arch when its pretty much an automated build/binary blob installer? I dont know much but it really seems like the AUR could easily be made available on other distros and renamed to LUR.
AUR maintainer for a few niche packages here. It's because it lowers the barrier of entry. Remember this is all a volunteer effort.
What do I do when someone running ubuntu reports an error saying the PKGBUILD doesn't work?
What if the program fails due to a different version of the kernel? (True story, only after 2 weeks of debugging I found out that the user was running Manjaro, which used a different naming convention for the kernel)
What do I do if someone reports a missing library dependency on fedora? Should I also package that library for fedora?
If I'm packaging drivers for specific hardware. I'm not going to install a specific distro just to fix your issue (sorry!). Most of my advice is given on a best effort basis. I made these build scripts for myself since I want native installs for all my software, and thought other people may be interested in them as well. If the responsibility of maintaining them becomes too overwhelming (like with your LUR case). I'll probably host these build scripts in a private repo instead.
Fair enough. Would still be cool if we had a single pkgbuild client that could pull from repositories that host packages that are compatible for a given distro. Keep the AUR for Arch users, but have Fedora, Ubuntu etc. repos for users on those distros and their particular setups/dependencies etc. It's more the technology of AUR that I think would be good for all of linux rather than the AUR's contents itself.
That, or I'll just wait for Vanilla/APX to get less janky.
Now that I think of it, if i follow it to the logical conclusions of using a container to build and manage dependencies for each individual package across multiple distros all I've come up with is a self-building flatpak and/or VanillaOS 👀
The AUR has more eyes on it though and can be more up to date. Getting OBS plugins "wrapped" was a pain in the ass in NixOS and they were out of date. But I'll admit it's a pretty niche example.
Yeah I was on unstable. This was a few months ago and the plugin was obs-backgroundremoval which was several versions out of date and missing out on a CPU core restriction feature that I needed. The maintainer actually had updated the package in his personal repo but it hadn't been pushed to nixpkgs unstable because it was waiting on some graphics library that hadn't been updated. I'm a huge Nixos noob and no matter how I tried to install the package from the maintainer's repo I couldn't get it installed or properly wrapped and the documentation sucked. I spent several days trying to resolve the issue.
I installed Endeavouros, ran yay -S obs-backgroundremoval and boom installed, latest version, no problems.
Don't get me wrong I actually love the ideas behind Nixos and I've tried to run it as my daily driver a few times now but I always seem to run into some problem. I'm more than happy to chalk it up to skill issue. This is my daily driver though that I use for school. It doesn't necessarily need to be stable but I need it to work and I need to understand it.
That's basically just some software is not up to date. I did the pull request to package it myself, it wasn't so difficult. The best part is I used an overlay so I could run it and use it while the pull request was being commented on
Any reason not to just use yay? That's an alias for yay -Syu, which in and of itself, at least if I understood it correctly, is basically just pacman -Syu and from what I've read on the arch wiki-Sy is heavily discouraged.
yay in the example was used to install an AUR; not to update the system which is what you are talking about. And the discouragement you speak of -Sy applies only to pacman upgrades, not AUR helpers. The only reason the y is discouraged in the wiki when installing a package is because it fetches updated data from the repos which might lag the rest of the system (and potentially the resulting dependencies if any). Most of the time it is not a concern as most (quality) software is made to be backwards compatible anyway.
There are so many software devs that package AURs because Arch has made it easy for them to do so. No need to give examples if you are totally fine with your brand of distro.
But whether you'll hit the minor snag OP memes about depends on your software needs.
But then you are installing it locally. The benefit to containers is they can be deleted. Containers allow you to have separate systems that are not apart of your main system. This keeps everything clean so you don't have to worry.
Also Arch is a unstable mess and requires updates way to frequently
I've been using Arch for over a decade now. On a laptop, desktop, VPS and now it's also driving Steam OS on the Deck. I had very little problems with it compared to our Ubuntu setups at work that randomly break on updates. Ubuntu is not as bad as it used to be but from my experience (i.e. the way I use it), Arch has been more stable and reliable.
I haven't tried not touching it for years to be honest. Longest period without a reboot was something between half a year and a year and it worked without a problem. Check the Arch website, breaking changes or manual interventions are very rare nowadays. There's just one thing you have to do if you start an update after a long time: make sure to update the keyring first or pacman will exit with an error. That's also mentioned in the wiki.
I installed Arch on my server because:
I know it very well.
The base system is tiny. Fewer packages = fewer problems. Everything else is in Podman containers anyway.
It's very flexible. I have a customized encrypted rootfs which needs to be unlocked through SSH, not a very common thing I guess.
No, you need to do system maintenance on Arch at least once a year if you don't do it after each update. You need to merge configs (I love etc-upgrade from gentoo for this) and find and delete orphaned packages left behind by the rolling release that are still on your system.
But then your installing it locally. The benefit to containers is they can be deleted.
This does not make any sense in this context. Or anywhere else if you want to get real pedantic.
Also Arch is a unstable mess and requires updates way to frequently
Arch can beunstable at times but that's part of the deal as is with any distro you'll install and use over time. Requiring updates frequently is also not a valid argument against Arch as you can choose when to update.
Arch ships to new of packages for my comfort. This leads to breakages if you don't read the update notes. I want my system to stay updated automatically and Arch causes to many headaches.
Software updates can potentially cause issues in general. This situation is not unique to Arch.
There's nothing wrong with a rolling release model where you get newer software that's closer to upstream. In most cases, you get security updates faster and in some instances you get bug fixes & new features from upstream that will take weeks if not months to hit "stable" distros.
...or nixpkgs they have the most packages of any distro (although, I don't know if they also count all the language specific libs like from pypi, npm, crates, etc.)
Yes, most packages are auto-generated from those. When it comes to manually generated packages AUR should still be #1. Not that I ever missed any packages in nixpkgs...
Same. Yesterday, I found Vulkan drivers for virtual machines (vulkan-virtio) , but it's packaged only for archlinux. And I gave up trying to build from source yesterday.
What software only works on Arch? If anything I see stuff that’s packaged for arch but can be installed from source on other distros without issue.
Ubuntu-only software, on the other hand, is infuriating
There's a lot of content packaged for the AUR that isn't readily available to people using less enlightened distributions.
I use Arch BTW.
Seriousposting: a lot of software just isn't packaged as deb or rpm because no one has taken the time to do it. The AUR is really fucking convenient as an end user. And yes, you should always skim AUR packages to be sure they're doing what they claim to do and aren't garbage, anyone can post anything. I have seen a lot of trash uploaded to the AUR.
I used to think the A in AUR stood for anarchy
OP said “only available for Arch” not “only packaged for Arch”. These are not remotely the same thing.
I uSe ArCh AnD tHeReFoRe PoSeSs A uNiQuE aBiLiTy To RuN make fRoM a TeRmInAl!!!1!
There are many things that can stop me from running a program but what distro I'm using is not one of them.
Become distro-agnostic. Don't be afraid of source code.
Seriously, look at what the pkgbuild is doing on Arch and replicate it by hand on your distro of choice. That's all a pkgbuild is: a simple bash installation script.
I like your funny words, computer man. 👉😀👉
I use KDE Neon, btw.
based distro kde #1
have fun translating all the package names!
True but dependency hell and maintaining updates for that is a headache I wish not to deal with.
AppImage and Docker has resolved a lot of that for me if its not in my distros package manager. It's my goto for the same reason of just not wanting to deal with it.
How do you use appimage for binaries built from source?
Premade AppImage or self-contained binary, I'll usually drop it into ~/.local/bin.
Something I have to compile, I'll usually do in a dockerfile tracked in my dotfiles repo.
Only thing I've compiled from source on my host in the last year is https://github.com/werman/noise-suppression-for-voice.
Could just be my use cases now compared to 10 years ago, but I've just found I'm rarely compiling these days on the host system. At least the configure-make-install or ninja variety. I'm sure I install a package here or there that does it in the background. Numpy comes to mind or an AUR package with Arch.
Configure and make are your best friends.
Just don't worry about timely updates.
You mean I shouldn't
git pull; git checkout HEAD; sudo make installevery day?Just add trap 'echo ""${last_command}" No updates available at this time"' EXIT afterwards, in case the build fails ;) Might take a second to determine lol
Typical Artix problem, I know the feel.
Distrobox is your friend. Me, I like an immutable OS (kinoite) but I still want the AUR...
Try it, you might like it !
Also great when you get some software as a deb for old Ubuntu and don't want the trouble of manually making it work on a new system. Just make an old Ubuntu distrobox.
Ooh, a fellow Kinoite user!
I'm actually aware of Distrobox, but the thing I had in mind was for managing gaming wheel drivers, so I don't think it'd work on distrobox. It's not really that big of a deal honestly, I just made this meme to poke fun at it ^^'
Fair enough, but CUDA stuff works surprisingly well for e.g., I'd give it a go if it's just USB.
Kinoite Represent!
./configure
make
sudo make install
Thanks, Now excuse me while I put a million compiler flags to optimse my program by 1 nanosecond and contemplate the reasons for human existence.
Later: how to uninstall this app?
And so the journey continues, deep into the forest of antiquated build systems and bleeding edge dependencies
I hope you configure it to install to .local
Na that's what the sudo is for muahahahahahaaa 😅
Deleted
You beat me to it! I also use Arch BTW.
I use Arch BTW.
But also I feel like handing a AUR manager to a person is like giving them a block of C4 and a detonator and saying "good luck"
Stupidly powerful, but you can blow your hand or foot off in a second if you're not aware
You Linux people are funny.
I just download the Windows versions and run them with Wine.
I don't understand any of this, my windows install is on a 120GB SSD, it's full now and I can't update my graphics driver.
True story for some stupid ethernet driver patch: alx-wol-dkms
TFW you're caught between being an average person and tech nerd wizard, just competent to copy/paste ubuntu-based install instructions in the terminal but get a headache trying to compile from source. I use Mint, btw.
I consider myself relatively familiar with linux, people come to me when they have issues or need help setting something up
But compiling stuff from source? That still gives me headaches 😩
AUR is love, AUR is life 🙏
AUR stronk
Very very very rarely some stuff on it is sometimes orphaned or outdated, but it's really fucking great to simply "paru" and the thing I want.
This is what always leads me back to arch. I can follow an outdated 12-step guide to installing the software in Debian or I can install it with one command from AUR.
Depending on the software, you can use it inside an arch Linux distrobox with yay or some other helper
./configure && make && sudo make installGet off my lawn.
I copy pasted this in my terminal and got an error. Apparently my Linux doesn't know
&&I can't imagine that's true.
It automatically converted the code, I edited the comment
I'm a noob, isn't every (open source) program aviable for every distribution if you compile it from source? It's all Linux in the end (i never compiled a program from source, so I don't know if it's easy at all)
Some programs may use libraries or tools specific to a distributions package manager. For example, yay, an AUR helper/pacman wrapper. You would have a very hard time getting it to work on Debian.
Other programs might only include build scripts for a distro specific build system. For example, a program might skip using a Makefile, and do everything in the Arch-specific PKGBUILD.
Generally though, most software uses a standard cross-distro (or even OS) build system. In this case, compiling from source would be an option on any distro. The program might still only be packaged for Arch/NixOS/Gentoo (or others), as it is a very simple process to do so.
Usually the only tricky part of compiling from source is tracking down dependencies. The package manager does that for you normally but you're not using the package manager when compiling from scratch. The actual building (even compiling a kernel) isn't all that complicated.
Usually developers list dependencies in README anyway
True. It's the dependencies of dependencies where the tricky part starts.
Dependencies almost always are present in distro repos. What's tricky?
If you need the python header files, depending on your distro, you may need to install python3-dev, python3-devel, python3, or some other variation on the name. For a novice, this might not always be obvious and they might not know things like
apt-fileare helpful for figuring it out.Huh. Shouldn't apt install header dependencies too? I'm using system where every package comes with headers, so I don't install headers separately.
Debian and RedHat based distros typically do not bundle them together. The have separate
-devand-develpackages for headers.Yes, but not every package is in every repository
fr though why is the AUR specific to Arch when its pretty much an automated build/binary blob installer? I dont know much but it really seems like the AUR could easily be made available on other distros and renamed to LUR.
AUR maintainer for a few niche packages here. It's because it lowers the barrier of entry. Remember this is all a volunteer effort.
What do I do when someone running ubuntu reports an error saying the PKGBUILD doesn't work?
What if the program fails due to a different version of the kernel? (True story, only after 2 weeks of debugging I found out that the user was running Manjaro, which used a different naming convention for the kernel)
What do I do if someone reports a missing library dependency on fedora? Should I also package that library for fedora?
If I'm packaging drivers for specific hardware. I'm not going to install a specific distro just to fix your issue (sorry!). Most of my advice is given on a best effort basis. I made these build scripts for myself since I want native installs for all my software, and thought other people may be interested in them as well. If the responsibility of maintaining them becomes too overwhelming (like with your LUR case). I'll probably host these build scripts in a private repo instead.
Fair enough. Would still be cool if we had a single pkgbuild client that could pull from repositories that host packages that are compatible for a given distro. Keep the AUR for Arch users, but have Fedora, Ubuntu etc. repos for users on those distros and their particular setups/dependencies etc. It's more the technology of AUR that I think would be good for all of linux rather than the AUR's contents itself.
That, or I'll just wait for Vanilla/APX to get less janky.
You're thinking of the OBS (open build service), which does exist.
I think it might be because of dependencies that might not be the same version on other distros
Now that I think of it, if i follow it to the logical conclusions of using a container to build and manage dependencies for each individual package across multiple distros all I've come up with is a self-building flatpak and/or VanillaOS 👀
I use arch btw
distrobox for most cases should be fine...
Funny meme. NixOS has more packages than the AUR
The AUR has more eyes on it though and can be more up to date. Getting OBS plugins "wrapped" was a pain in the ass in NixOS and they were out of date. But I'll admit it's a pretty niche example.
Nixpkgs is up to date on unstable
https://search.nixos.org/packages?channel=unstable&from=0&size=50&sort=relevance&type=packages&query=obs
it's on 29.1.3 which is the latest non-beta release
The plugins:
https://github.com/exeldro/obs-3d-effect
3d-effect-0.0.2 is the latest one
https://github.com/obs-ndi/obs-ndi
obs-ndi 4.11.1 is the latest one, so nixpkgs is two versions behind
https://github.com/phandasm/waveform
1.7.0 is the latest
Yeah I was on unstable. This was a few months ago and the plugin was obs-backgroundremoval which was several versions out of date and missing out on a CPU core restriction feature that I needed. The maintainer actually had updated the package in his personal repo but it hadn't been pushed to nixpkgs unstable because it was waiting on some graphics library that hadn't been updated. I'm a huge Nixos noob and no matter how I tried to install the package from the maintainer's repo I couldn't get it installed or properly wrapped and the documentation sucked. I spent several days trying to resolve the issue.
I installed Endeavouros, ran yay -S obs-backgroundremoval and boom installed, latest version, no problems.
Don't get me wrong I actually love the ideas behind Nixos and I've tried to run it as my daily driver a few times now but I always seem to run into some problem. I'm more than happy to chalk it up to skill issue. This is my daily driver though that I use for school. It doesn't necessarily need to be stable but I need it to work and I need to understand it.
That's basically just some software is not up to date. I did the pull request to package it myself, it wasn't so difficult. The best part is I used an overlay so I could run it and use it while the pull request was being commented on
Well I'm glad you're able to figure it out. I might give it another go next summer when I have more time to look into things.
*only if you count different versions as different packages.
well, you can't INSTALL the old versions on another system if the dependencies don't match the old version
TIL ! Do you where i can see the current statistics ?
Don't know what statistics you want exactly, but you can search for packages here: https://search.nixos.org/packages
https://repology.org/repositories/statistics/total
This is not a problem, I use garuda btw.
Fly high, my friend.
Can't you just use it though distrobox and podman?
Not as easy or as convenient as
yay -Sy appnameit actually is, you just append the distrobox command before it
distrobox enter arch -- yay -Sy appnameA simple
yay -Syfrom Arch btw takes less computing power and doesn't depend on an external dependency.Any reason not to just use
yay? That's an alias foryay -Syu, which in and of itself, at least if I understood it correctly, is basically justpacman -Syuand from what I've read on the arch wiki-Syis heavily discouraged.yayin the example was used to install an AUR; not to update the system which is what you are talking about. And the discouragement you speak of-Syapplies only to pacman upgrades, not AUR helpers. The only reason theyis discouraged in the wiki when installing a package is because it fetches updated data from the repos which might lag the rest of the system (and potentially the resulting dependencies if any). Most of the time it is not a concern as most (quality) software is made to be backwards compatible anyway.But then you stuck with arch. I've never had any software that wasn't a flatpak or in the Debian repos. I use Fedora.
I would say you are stuck on Fedora too, what is your point?
There are quite a number of them, hence the reason for OP's meme.
Really? I honestly have never had that problem. Can you name a few? (I'm completely serious. Don't take this as sarcasm)
There are so many software devs that package AURs because Arch has made it easy for them to do so. No need to give examples if you are totally fine with your brand of distro.
But whether you'll hit the minor snag OP memes about depends on your software needs.
But then you are installing it locally. The benefit to containers is they can be deleted. Containers allow you to have separate systems that are not apart of your main system. This keeps everything clean so you don't have to worry.
Also Arch is a unstable mess and requires updates way to frequently
I've been using Arch for over a decade now. On a laptop, desktop, VPS and now it's also driving Steam OS on the Deck. I had very little problems with it compared to our Ubuntu setups at work that randomly break on updates. Ubuntu is not as bad as it used to be but from my experience (i.e. the way I use it), Arch has been more stable and reliable.
I have also had issues with Ubuntu. I just stick with Debian because I don't have to touch it for years.
Can you do the same with Arch? Also why do you need newer packages on a server? (I'm taking about the VPS)
I haven't tried not touching it for years to be honest. Longest period without a reboot was something between half a year and a year and it worked without a problem. Check the Arch website, breaking changes or manual interventions are very rare nowadays. There's just one thing you have to do if you start an update after a long time: make sure to update the keyring first or pacman will exit with an error. That's also mentioned in the wiki.
I installed Arch on my server because:
No, you need to do system maintenance on Arch at least once a year if you don't do it after each update. You need to merge configs (I love etc-upgrade from gentoo for this) and find and delete orphaned packages left behind by the rolling release that are still on your system.
https://wiki.archlinux.org/title/System_maintenance
This does not make any sense in this context. Or anywhere else if you want to get real pedantic.
Arch can be unstable at times but that's part of the deal as is with any distro you'll install and use over time. Requiring updates frequently is also not a valid argument against Arch as you can choose when to update.
Arch ships to new of packages for my comfort. This leads to breakages if you don't read the update notes. I want my system to stay updated automatically and Arch causes to many headaches.
Software updates can potentially cause issues in general. This situation is not unique to Arch.
There's nothing wrong with a rolling release model where you get newer software that's closer to upstream. In most cases, you get security updates faster and in some instances you get bug fixes & new features from upstream that will take weeks if not months to hit "stable" distros.
That's fine if you like that kind of thing. However it isn't for everyone
Sorry to be a grammar nazi but that's the second time and it annoys some of us. It's literally a different word with a different meaning!
...or nixpkgs they have the most packages of any distro (although, I don't know if they also count all the language specific libs like from pypi, npm, crates, etc.)
Yes, most packages are auto-generated from those. When it comes to manually generated packages AUR should still be #1. Not that I ever missed any packages in nixpkgs...
You can install their package manager on your distro of choice
Maybe possible for some packages, but, a package manager main reason for existing is usually handling dependencies so as to not result in conflicts.
Definitely something that sounds easy, but is likely far from it for packages that have a deep tree of dependencies
Same. Yesterday, I found Vulkan drivers for virtual machines (vulkan-virtio) , but it's packaged only for archlinux. And I gave up trying to build from source yesterday.
or only as appimage
Skill issue (I use arch btw), all jokes aside maybe try distrobox it should work perfectly
lxc-make.sh arch -d arch
Make yourself a quickie container and install it there, my base config has x11 forwarded with opengl.
That'll work but distrobox is a much simpler solution
me trying to install Davinci
SCREAMING
TBF I found the first party packaging tools for Debian are very hard to use. I always end up using nFPM or makedeb anyway
Is it open-source or closed-source?
simply destroy arch
Here is an alternative Piped link(s):
Anakin
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I'm open-source; check me out at GitHub.
Maybe OpenSUSE if you're lucky