Managing aur package without aur helper

tonitch · 2020-08-17 07:42:06

Hello, i'm using arch for quite some times now ans i have notice several page on the wiki that sais that the intended way to use aur is clearly not aur helper and that we should build package by ourself...

I already clone package and installed some especially on some device where I avoid the use of helpers but a question still remain

What is the efficient way to jeep track of all my aur package? My though was to make a dir called aur and clone every package one by one then just sometime go to git pull every one of them then rebuild those with update but it seems like a long task for not so much... Even with a script and I have 2 laptops 1 raspi and 1 desktop running arch... If I have to do this to all of them its quite some Time consulting
..

Soo m'y question is what is the best way to manage aur packages if I follow arch guidelines by not using helpers ?

Awebb · 2020-08-17 08:26:45

A script that checks the git repos for updates and then rebuilds the packages, sounds good, that's what I am doing.

d_fajardo · 2020-08-17 08:35:26

If you're using conky, Xyne's paconky is an excellent script that checks for both pacman and AUR updates.

EDIT: This script doesn't update the packages. Just tells you if there's an available update.

Last edited by d_fajardo (2020-08-17 08:37:07)

mpan · 2020-08-17 08:35:38

AUR helpers are discouraged to people, who do not understand packaging process or what AUR is. There is nothing wrong in using scripts to automate at least a part of the process. And since other people have already written the relevant scripts — the AUR helpers — it is a sane idea to use them instead of reinventing a square wheel.

Just be sure you really understand the process and not using the helper as a black box that magically produces software on your computer.

A separate issue are AUR helpers that are simply broken, like yaourt was. But this is not because all AUR helpers are bad, but because some are written bad. Just ask people around, what helper works. You may also check the comparison tables. Skip anything that doesn’t support file review or has no reliable parser. Other features are more optional, but expect problems if split packages are not supported.

I am not using any helper right now, as I do not need it anymore (not much AUR-based stuff installed), but you may take look at aurutils (AUR) if you want not a complete AUR helper, but a set of tools to build your own AUR workflow.

Pulling AUR repos periodically is what I am doing, but I do not have much to pull in the first place. You should also remember that some AUR entries remain unupdated even if upstream updates. You may list your foreign packages using the one-liner below to see which one are very old. Uses extra/expac. Note that it lists ALL foreign packages, not only those built based on AUR:

pacman -Qmq | xargs expac --timefmt='%Y-%m-%d' '%b %n' | sort

If something gets too old, you may investigate what’s the cause.

Last edited by mpan (2020-08-17 08:37:24)

eschwartz · 2020-08-17 13:51:27

mpan wrote:

A separate issue are AUR helpers that are simply broken, like yaourt was. But this is not because all AUR helpers are bad, but because some are written bad. Just ask people around, what helper works. You may also check the comparison tables. Skip anything that doesn’t support file review or has no reliable parser. Other features are more optional, but expect problems if split packages are not supported.

pacaur is on that list and has all green boxes (and always has), which is the surest sign the comparison table is more or less worthless. pacaur is far, far, far worse than yaourt ever was, which I know because I've read the code for both of them.

yaourt was the most recommended to newbies, so it got most of the bad rap through association, and occasionally the bad rap was even deserved due to unfortunate bugs (every AUR helper has its bugs, and yaourt was certainly not the best; aurutils, maybe).

pacaur was used by people who fell for the developer's elitist "I'm better than other AUR helpers" superiority complex, and rarely got a bad rep despite a number of unfortunate bugs which the developer refused to acknowledge as bugs, and therefore would not fix. On top of this, it suffered from being a platform for the developer's political statements about AUR packages, and frequently built package successfully but then refused to install them, emitting false error messages in order to trick users into complaining in the AUR comments. It also reads pacman.conf and uses it to decide whether to pass --nocolor to makepkg... Fortunately, pacaur is pretty much dead.

yay is a rewrite of yaourt in golang, its name literally stands for "yet another yaourt". It's thematically fairly similar, though it adds new bugs like hammering the AUR RPC and getting you rate limited for a 24-hour blacklisting of your IP address if you try to install certain packages with complex deptrees. So much for being the current new favorite.

yaourt is still, I think, the only pacman wrapper ever which actually warned people AUR packages are unsupported, and in fact does so in red blinking text just to hammer the point home. All the new boutique pacman wrappers blur the distinction entirely.

Awebb · 2020-08-17 18:06:31

I prefer search helpers like auracle, that can search the aur, search for updates and show the buildorder. If it wraps around pacman, it's usually buggy or does things in a weird way.

Trilby · 2020-08-17 18:20:08

tonitch wrote:

Even with a script and I have 2 laptops 1 raspi and 1 desktop running arch...

With multiple systems of the same CPU architecture, you could benefit from running a custom local repo, so you build the package once and install it on all the machines. Alad's project (is it called aurtools ... something like that) is designed to help automate this approach, but even just building with makepkg and dumping the build package into a shared directory (and setting it up with repo-add) would get you there.

But note you'd still need to build for each architecture - specifically, at least the r-pi would be an odd man out for that.

If you have AUR packages that are time and/or resource intensive to use, the benefits of the local repo start really coming out. If your AUR packages are not that hard to build though you'll have to balance the benefits of a local repo against the simplicity of just running makepkg on each machine whenever you really want the AUR package updated.

Also keep in mind that - for the most part - AUR packages don't need to updated as soon as an update is available (sometimes, if there are changes in dependencies, but otherwise if they work they work). For example, I use st-git for my terminal. As long as it keeps working, I only bother updating it every couple months or so (and that's even a trivial to rebuild/update package).

Last edited by Trilby (2020-08-17 18:23:58)

Arch Linux

#1 2020-08-17 07:42:06

Managing aur package without aur helper

#2 2020-08-17 08:26:45

Re: Managing aur package without aur helper

#3 2020-08-17 08:35:26

Re: Managing aur package without aur helper

#4 2020-08-17 08:35:38

Re: Managing aur package without aur helper

#5 2020-08-17 13:51:27

Re: Managing aur package without aur helper

#6 2020-08-17 18:06:31

Re: Managing aur package without aur helper

#7 2020-08-17 18:20:08

Re: Managing aur package without aur helper

Board footer