It makes all the classic mistakes like 1000 prompts per package, sourcing PKGBUILDs for dependency information, using fragile adhoc methods for JSON, etc.
Anyway I don't blame you for it. It's the sort of stuff you get when you base your design on pacaur
's horrendous code-base.
My suggestion: keep using pacaur
, it was already updated for pacman 5.1 anyway despite its apparent abandonment. You'll save yourself a world of hurt.
I've been using pacaur
for years now, basically ever since the first incarnation of bauerbill
was taken down. It does the job, has colourised output, and it's actively developed. It is based on cower
, but a port to auracle
is in progress.
I do have a couple of grievances, though: - It doesn't support automatically removing orphan makedepends at the end of a build (which is intentional); - If you are trying to install multiple packages at once and any one checksum or build fails, no package will be installed. This is quite a nuisance, since sometimes it won't be clear exactly which package is at fault.
pacman
does not have the capability to check for updates for packages outside of the repositories it knows, hence not for packages installed from the AUR. For that, you need to either check manually or use an AUR helper like pacaur.
Of course! There are quite a few "AUR helpers" : https://wiki.archlinux.org/index.php/AUR_helpers
Pacaur is the prefered choice by many. Just manually install it and then you use it exactly like pacman.
pacaur -Syu
the above command will update everything, both the official repos and AUR. You don't even have to use pacman -Syu. It can also install both from aur and official repos with pacaur -S.
For more info and commands see the official github repo for pacaur: https://github.com/rmarquis/pacaur
I never knew who you were before today and this is the second time I see your name, and your toxic behaviour. You are wasting your time with me, I don't care about your opinions.
That won't update AUR packages. For that you need an AUR helper like pacaur. Since pacaur is also a pacman wrapper, you can update both official and AUR packages with pacaur -Syu
, if you like.
I recently switched from yaourt to pacaur, and while pacaur (as advertised) doesn't suck, it doesn't blow my mind either.
In particular, the standard output feels like a downgrade to me. (versions of software upgrades are not highlighted like they are in yaourt) Is there any way to get such an output with pacaur ? (I don't see relevant options in the README, and examples I managed to find only show such an output for AUR packages)
Note: I'm new to pacaur and away from my Arch machine, sorry if I'm misinformed or missing something obvious.
You're right, for most things sudo is going to be called. Check out the Digital Ocean link I posted though. They instruct people to download the script, open it up, and then run it after inspecting it. This isn't foolproof because Bash is a fucky language that's easy to obfuscate, but it puts folks in the right frame of mind.
You're correct about the GUI installers. This is why I like Linux so much over Windows, most package managers will verify that what you downloaded was signed by a trusted PGP key before they'll install anything. There's issues with getting a crap PGP key, but it's turtles all the way down at that point. As a counterpoint, I believe that Windows has something kind of similar, although much shittier. I believe it only applies to drivers, but if your driver isn't signed Windows will warn you before you install it.
It's true that nvm is just bash. It is, however, a very popular tool built specifically to support NodeJS. I suppose a good analog would be something like pacaur for Arch Linux. It's not necessary to have, but it's a very useful and powerful tool used by many in the Arch community. Nowhere are you prompted to curl | bash. The installation method requires user interaction, and you're strongly encouraged by official documentation to check what you're actually installing. It's not the best comparison to make because pacaur makes a point of being somewhat difficult to install to ensure that only people who know what they're doing use it, but the point still stands. I really like the approach DigitalOcean takes. They at least make people aware of the dangers of running code from the internet.
I'll take a punch at my favorite community as well. pip is a stupid package manager because it relies on just HTTPS. They should at least verify checksums. PGP signing would be ideal, but it's kind of unrealistic for the way they operate. pip is one of my least favorite parts of Python.
Thanks. I've opened an issue on GH. The bash output isn't very informative, but I've posted a link to it anyway. Any help with pinpointing the issue is welcome! It seems to be a different issue from #264, since using curl alone works.
EDIT: I just saw your edit and checked the permissions. Both "ignoretmp" and "rcp.json" were owned by root. Problem solved! Thanks! I'll close the GH issue.
Pacaur Github is archived.
Forum post regarding the maintainer decision.
Pacaur on AUR the last update was 2 years ago.
It still works but it hasn't received any updates recently....
curl -L https://github.com/rmarquis/pacaur/archive/4.6.9.tar.gz --output ~/Desktop/new
this worked actually. But i still can't do all the other things described above.
Trust me when I say there's no fun to be had with implementing local repos. If you really hate yourself, I did a partial write-up here: https://github.com/rmarquis/pacaur/issues/643#issuecomment-290906331
>Ideally I want to take your idea of aurutils and convert it to a library. So components for fetching, dependency resolving and maybe building.
It's already fully compartmentalized, and probably the only helper that is. (In the sense that components can be used independently.)
It's just in bash
, because I never saw the benefit in using a more powerful language - the AUR is chock full of a bugs that you'll have to use ugly methods no matter what you do. That said, I've been playing with the idea of a libaur
(in C), which would be a common thing for AUR helpers to use. A bit like libalpm
. Johannes made some efforts, based on the cower code base.
Considering AUR upstream has very little interest in supporting helpers or any functionality aimed towards them, that might be the way moving forward. If you want to have fun, that's the place where I suggest having it.
>Pacman extension operations
> -S, -Ss, -Si, -Sw, -Su, -Sc, -Qu
>Pacaur wraps all pacman operations and by default extends respectively its install, search, info, download only, update, clean and check updates functions to the AUR. Pacaur will also pass any other pacman operations and their related options to the pacman binary.
https://github.com/rmarquis/pacaur
Options for pacaur are the same as pacman
Yes it is only root editable,why?.There is however an option to modify a file to affect only specific users while keeping the root user on default but i didn't look into that and i don't know if ypu still need root to modify it.
https://github.com/rmarquis/pacaur/blob/master/README.pod#___top
of course, you can see it failing to update itself in the logs. this also doesn't matter one bit, since the error comes via libcurl->makepkg. i've updated it manually just now and sure enough nothing changed.
what happens when you curl -I https://github.com/rmarquis/pacaur/archive/4.6.10.tar.gz
and curl -I https://codeload.github.com/rmarquis/pacaur/tar.gz/4.6.10
(which the first one redirects to)?
Update: I've gone with Antergos, dual booting. So far, pretty happy. I use pacaur (https://github.com/rmarquis/pacaur) for package management, which keeps the AUR packages in sync (as well as everything pacman does). Basically, I managed to get Arch with a painless installation process, it seems.
Thanks all for the suggestions!!
Well I've found out that the builddir is most probably /tmp ...
https://github.com/rmarquis/pacaur/blob/master/pacaur#L42
However, if I understand that script correctly, it will not save those files anywhere except at BUILDDIR, which will be cleaned on reboot...
I don't really see the point of this (modifying -git release at each update, really?), but I'd simply make a few changes in pacaur.
Adding "continue" just before the builds start might be a good starting point.