pacaur - an AUR helper that minimizes user interaction

Trilby · 2017-12-26 20:45:37

Linkjay wrote:

I mean on the PKGBUILDs eventually being removed from the AUR. When is that supposed to happen? I wasn't aware. What's going to be used instead? Why?

Presumably Spyhawk will abandon the package(s) after the last aforementioned update. Then they will be removed from the AUR whenever there is a cleanup/purge of orphaned packages which happens periodically, but I don't know of any official schedule for it.

What's going to be used instead? Whatever you want, just not pacaur.

Why? Read the last page of posts in this thread.

ewaller · 2017-12-26 21:04:41

Well. Spyhawk: So long, and thanks for all the fish. I have migrated away, at your suggestion but I really want to thank you for your time and effort over the years on this project.

Linkjay · 2017-12-27 06:05:48

Trilby wrote:

Linkjay wrote:
I mean on the PKGBUILDs eventually being removed from the AUR. When is that supposed to happen? I wasn't aware. What's going to be used instead? Why?
Presumably Spyhawk will abandon the package(s) after the last aforementioned update. Then they will be removed from the AUR whenever there is a cleanup/purge of orphaned packages which happens periodically, but I don't know of any official schedule for it.
What's going to be used instead? Whatever you want, just not pacaur.
Why? Read the last page of posts in this thread.

Ohhhh. So he means that he's going to remove the PKGBUILDs from the pacaur pkg. That makes a lot more sense. I thought he meant that the AUR maintainers were planning on scrapping use of PKGBUILDs and do something else.

Thanks for the clarification.

eschwartz · 2017-12-27 16:17:51

No, it's the other way around. Spyhawk will orphan the package, and the assumption is that pacaur will then be deleted from the AUR.

But this is a wrong assumption, a popular package that has people interested in it will not be deleted simply because the upstream maintainer stopped developing it -- if that were true, the AUR would be a much more lonely place and people wouldn't have a lot of cool programs.

Packages might get purged if they have no votes, no comments, no maintainer, and were last uploaded a long time ago. The assumption there is that no one is actually interested in it, so why should it clog up the search results as a waste of space?

progandy · 2017-12-27 16:54:51

Eschwartz wrote:

No, it's the other way around. Spyhawk will orphan the package, and the assumption is that pacaur will then be deleted from the AUR.
But this is a wrong assumption, a popular package that has people interested in it will not be deleted simply because the upstream maintainer stopped developing it -- if that were true, the AUR would be a much more lonely place and people wouldn't have a lot of cool programs.

I assumed that a future pacman or aur upgrade will break pacaur, and the now broken software will be removed from the AUR. That may not happen if someone else adopts it and fixes any bugs.

eschwartz · 2017-12-27 17:40:54

Sure, if that happens. But I'm not aware of any current plans to make breaking changes to either one.

bulletmark · 2017-12-27 21:34:45

Eschwartz wrote:

Sure, if that happens. But I'm not aware of any current plans to make breaking changes to either one.

Spyhawk stated a page back here that pacaur will start breaking when pacman moves to 5.1.

eschwartz · 2017-12-28 00:18:53

I'm trying to think why that would cause a problem, but I'm drawing a blank.

glyons · 2017-12-28 00:39:49

When is pacman moving to 5.1?

Is there a guesstimate?

Spyhawk · 2017-12-28 10:29:21

Spyhawk wrote:

The stable version will continue to work as it currently does for the foreseeable future, with some issues becoming apparent starting from the pacman 5.1 release.

There are issues related to makepkg not creating symlinks anymore that will trigger under specific condition, and to pactree which is moving from pacman to pacman-contrib. There are (partial) quick workarounds already in the git master branch, but quite of the directly affected code is rendered obsolete anyway.

I wouldn't encourage a fork. The code tripled in size over the years for various reasons, with only a few minor features added. It is hard to read and painful to debug, and I don't expect anyone to be able to maintain it in any meaningful way. This is mostly what motivated the idea of a thorough rewrite: the idea came to mind as early as 2014-2015 only to be further delayed, and the last year of discussion about it only reinforced my opinion that a rewrite from scratch would be much faster than a series of incremental changes.

No ETA for pacman 5.1. A rough guesstimate could be 6 months.

Last edited by Spyhawk (2017-12-28 10:29:56)

eschwartz · 2017-12-28 16:42:37

The symlinks could be fixed by either of the workarounds suggested in the past for fixing "mismatched .SRCINFO".
(I'm hoping my --packagelist patch will land soon.)

Adding pacman-contrib to the depends array for pactree is so trivial it doesn't even need pacaur changes.

SolarAquarion · 2018-01-02 00:28:25

Would it have been pacaur50 project?

Spyhawk · 2018-01-02 11:19:02

No, this branch was an early attempt at making incremental changes, but was eventually deemed too cumbersome to work with.

zaxdan69 · 2018-01-08 09:13:38

I'm using pacaur from a script to update aur packages via the command "pacaur -Syua".
The problem is that if one of the packages for some reason fail to update, then no packages updated at all.
Is there any way to change this behaviour, so the other packages to be updated?

Spyhawk · 2018-01-08 11:17:42

The --ignore flag is what you are looking for. Note that pacaur has never been designed for completely unattended update.

eschwartz · 2018-01-08 11:24:53

No, this is working as the author intended.

Also pacaur is no longer supported, so nothing will be fixed or changed anyway...

Last edited by eschwartz (2018-01-08 11:28:46)

zaxdan69 · 2018-01-08 12:02:24

Thanks, I' ll try it.

es20490446e · 2018-01-26 03:10:06

Bash, due to the way it handles variables, is very prone to bugs. And when they happen it doesn't inform well where they took place.

That's not a surprise because it's optimised for terminal operation, not programming, and designed a long time ago.

Likely rewriting the software in another language would solve the problem. It would make easy to discover errors, get contributors, and warrant its survival.

The ideal language would be Go, or alternatively Python.

Alad · 2018-01-26 14:16:27

es20490446e wrote:

...

Today in: "random claims daily".

eschwartz · 2018-01-26 15:30:59

es20490446e wrote:

get contributors, and warrant its survival.
The ideal language would be Go, or alternatively Python.

There are other AUR helpers written in both languages, and no one really contributes to them either.

However, the reason pacaur was abandoned and other AUR helpers weren't, is because the maintainer of pacaur no longer wished to be responsible for maintaining an AUR helper and (a thankless task) supporting its use by others.
I don't see how writing it in python, or the latest fad language, would help prevent that.

Last edited by eschwartz (2018-01-26 15:31:46)

aphirst · 2018-01-27 14:34:04

What are people actually migrating to, and why? The long list of other helpers is a bit opaque (yet sparse in detail), and it would be useful to have some real idea of how they differ without having to spend a day trying each out.

Trilby · 2018-01-27 14:50:20

It might be more productive to describe what features of pacaur were of greatest value to you. Knowing what alternatives best suit other people isn't really relevant - each user's perception of the "most similar" to pacuar will be largely influenced by which features they found most useful from pacuar.

aphirst · 2018-01-27 23:50:52

In that case, I specifically liked how:
* The control flags were essentially the same as for pacman
* One command would trigger update of repo + AUR packages
* AUR build folders were neatly (and transparently) in a .cache folder
* The AUR "stage" of operation still defaults to options like "inspect PKGBUILD" reinforcing the AUR's difference from the main repos, without being a burden

A lot of tools people seem to recommend are ones which basically require you to perform a totally different "style" of task to update the AUR, as if it's a good thing to keep the AUR as far as possible from system updating as possible. Some of them have a workflow which is several commands long, just to do what I personally think should be stitched onto the end of a normal -Syu. I just see this as giving oneself unnecessary work.

I'm going to miss pacaur.

Alad · 2018-01-28 00:27:31

The first points are reasonable, the rest is a nonsensical rant not worth responding to. So:

* The control flags were essentially the same as for pacman
* One command would trigger update of repo + AUR packages
* AUR build folders were neatly (and transparently) in a .cache folder
* The AUR "stage" of operation still defaults to options like "inspect PKGBUILD" reinforcing the AUR's difference from the main repos, without being a burden

Some helpers actually take the "one command" aspect further by making pacman itself the AUR helper. That is, AUR packages are kept in a pacman repository and pacman updates them together with other packages. Hooks, flags, etc. all apply.

The "inspect PKGBUILD" pacaur did was also hardly a bulwark of efficiency - you'd get one prompt per package (so potentially hundreds of prompts). Better is to use a file manager that displays everything in one window you can navigate, which again is what some helpers do.

Last edited by Alad (2018-01-28 00:35:50)

aphirst · 2018-01-28 08:46:40

Is there a reason you're not naming names?

Arch Linux

#676 2017-12-26 20:45:37

Re: pacaur - an AUR helper that minimizes user interaction

#677 2017-12-26 21:04:41

Re: pacaur - an AUR helper that minimizes user interaction

#678 2017-12-27 06:05:48

Re: pacaur - an AUR helper that minimizes user interaction

#679 2017-12-27 16:17:51

Re: pacaur - an AUR helper that minimizes user interaction

#680 2017-12-27 16:54:51

Re: pacaur - an AUR helper that minimizes user interaction

#681 2017-12-27 17:40:54

Re: pacaur - an AUR helper that minimizes user interaction

#682 2017-12-27 21:34:45

Re: pacaur - an AUR helper that minimizes user interaction

#683 2017-12-28 00:18:53

Re: pacaur - an AUR helper that minimizes user interaction

#684 2017-12-28 00:39:49

Re: pacaur - an AUR helper that minimizes user interaction

#685 2017-12-28 10:29:21

Re: pacaur - an AUR helper that minimizes user interaction

#686 2017-12-28 16:42:37

Re: pacaur - an AUR helper that minimizes user interaction

#687 2018-01-02 00:28:25

Re: pacaur - an AUR helper that minimizes user interaction

#688 2018-01-02 11:19:02

Re: pacaur - an AUR helper that minimizes user interaction

#689 2018-01-08 09:13:38

Re: pacaur - an AUR helper that minimizes user interaction

#690 2018-01-08 11:17:42

Re: pacaur - an AUR helper that minimizes user interaction

#691 2018-01-08 11:24:53

Re: pacaur - an AUR helper that minimizes user interaction

#692 2018-01-08 12:02:24

Re: pacaur - an AUR helper that minimizes user interaction

#693 2018-01-26 03:10:06

Re: pacaur - an AUR helper that minimizes user interaction

#694 2018-01-26 14:16:27

Re: pacaur - an AUR helper that minimizes user interaction

#695 2018-01-26 15:30:59

Re: pacaur - an AUR helper that minimizes user interaction

#696 2018-01-27 14:34:04

Re: pacaur - an AUR helper that minimizes user interaction

#697 2018-01-27 14:50:20

Re: pacaur - an AUR helper that minimizes user interaction

#698 2018-01-27 23:50:52

Re: pacaur - an AUR helper that minimizes user interaction

#699 2018-01-28 00:27:31

Re: pacaur - an AUR helper that minimizes user interaction

#700 2018-01-28 08:46:40

Re: pacaur - an AUR helper that minimizes user interaction

Board footer