Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to: navigation, search
m (`Reliable solver` discussion: deps list)
(Showing AUR comments as an important point for AUR helpers: rm closed)
 
(581 intermediate revisions by 22 users not shown)
Line 1: Line 1:
{{Note|'''Moderation''' — If your AUR helper does [[partial upgrade]]s ''without explicit user intervention'' (i.e, specifying {{ic|-Sy}} on the command line), it has no place on this page or anywhere else on ArchWiki. No exceptions. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:37, 20 September 2015 (UTC)
+
== "Reference" implementation ==
}}
 
  
== Comparison table - build directory ==
+
This is an alternative to [[Special:Diff/525492#Reliable Updater|#Reliable Updater]]. Instead of an arbitrary set of test packages, we could write up a "specification" on what a reliable AUR helper should do. This should also be more helpful for potential AUR helper writers who otherwise have to wade through complex, fully-featured AUR helpers.
  
Considering /tmp is mounted as tmpfs on Arch, and the potential downsides from building in RAM (running out of space), I think a column with the default build location for various helpers would be helpful.
+
I propose a minimal reference implementation with the following points:
  
The default values I've garnered so far, assuming TMPDIR is not set:
+
* No client-side workarounds for upstream limitations. In particular, a reference implementation does not need to score full points on split packages, as {{ic|makepkg --pkg}} was removed with pacman 5.
 +
* Minimal language constructs in e.g. a scripting language like {{Pkg|dash}}.
 +
* Prefer simplicity of implementation over being fully featured. In particular, an implementation may only support git clone and not git diff.
  
* aurutils: $XDG_CACHE_HOME
+
My initial plan was to keep such an implementation in a man page {{ic|aurhelper(7)}} (hosted as part of aurutils), but we can consider including on a sub-page of this article. It could be then linked from the comparison table. Thoughts? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:28, 8 March 2018 (UTC)
* pacaur: $XDG_CACHE_HOME (changed from /tmp, see [https://github.com/rmarquis/pacaur/commit/c5d750f75f040b21249fff100a2c8875348d03d1])
 
* bauerbill: $PWD/build
 
* pkgbuilder: $PWD, /tmp when specified with -S
 
* packer: /tmp (TMPDIR)
 
* yaourt: /tmp (yaourtrc)
 
  
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:16, 1 April 2016 (UTC)
+
: Generally agree with the idea, but I don't think there is a way around a set of PKGBUILDs that could be used to test helpers in a local AUR instance. F.e., I wouldn't define a "reliable" helper that doesn't handle split packages well. Since helpers are tolerated rather than supported, upstream limitations of the AUR might be temporary or permanent, meaning the limitation would actually be in the helper itself (f.e. like regex support). Also, I'd use pseudo code for such a reference as the actual implementation itself doesn't matter, unless you'd like to write a new minimalist helper. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 15:26, 8 March 2018 (UTC)
  
: Yes, this could be useful. Although you'd want not to use color here, since users that know what they're doing would prefer to use /tmp (or setting up BUILDDIR to /tmp). --[[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 11:15, 3 April 2016 (UTC)
+
::Apart from {{Bug|56602}}, I can't think of a case where upstream ''opposed'' removing limitations, even if helpers directly benefited. cf. the regex support discussed in [https://lists.archlinux.org/pipermail/aur-dev/2016-May/004036.html] or the exit codes finally introduced in makepkg 5.1 which made automatic building significantly easier imo. To me it seems that the main reason we have these AUR limations is due to the minimal interest of helper writers in contributing upstream, and upstream itself having different priorities. Not sure why former is the case, the PHP codebase may play part in it - at least it does for me.
 +
::You can keep ''dash'' close enough to pseudo-code, I guess less so if you want a complete example rather than exemplary code blocks. For the PKGBUILD set, I use this: [https://github.com/AladW/aurutils-test/blob/master/package.t#L11-L31] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:34, 8 March 2018 (UTC)
  
:: +1. see also [[#Multi-thread support]]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 11:33, 3 April 2016 (UTC)
+
::: My understanding is that changes that aren't invasive will be accepted upstream, but otherwise might be rejected (see [https://lists.archlinux.org/pipermail/aur-dev/2018-January/004421.html]). One prominent example that comes to mind is {{Bug|48796}}. It's not really relevant anymore since x86 has been officially dropped, but the solution would involve duplicating DB tables on the server, which isn't trivial to implement/migrate. Many of the feature requests involve non-trivial code change, which is the main reason nobody pushed patches; I dislike PHP but the language itself isn't too hard either. For regex, see the bottom of [https://lists.archlinux.org/pipermail/aur-dev/2016-May/004044.html], which is the follow-up of your link above.
::: Well, while it does have benefits for some users, it's still a bad default. As you say though, this is easy enough to change either way, unlike any of the behaviour described in the other columns.
+
::: Your testsuite seems interesting (thanks for the link), but one advantage of having a fixed set of packages is that these packages might be updated and change, making these edge cases difficult to test. This happened quite a few times with my own list of test packages in the past and this was rather annoying. [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 20:20, 8 March 2018 (UTC)
::: We could leave out the colors, but mention the drawbacks/benefits in the "meanings" paragraph. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:35, 4 April 2016 (UTC)
 
  
:::: It is bad default because some users have no idea about what they are doing, but this is strictly related to user preferences. Adding the meaning instead of colors sounds like the perfect solution to me. --[[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 14:35, 4 April 2016 (UTC).
+
== Expand Secure criteria to include other (non-PKGBUILD) bundled files ==
  
== Multi-thread support ==
+
[https://github.com/Jguer/yay/issues/493], in particular [https://github.com/Jguer/yay/issues/493#issuecomment-402522467]
  
This also made me wonder if tools differentiate regarding multi-thread support (seems related, e.g. cower has a defaulted option for it). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 11:33, 3 April 2016 (UTC)
+
The new criteria would be as follows:
 +
* PKGBUILD, no other files -> Partial
 +
* Other subset of files that includes the PKGBUILD -> Partial
 +
* No PKGBUILD -> No
 +
* All files in the git repo or tar archive -> Yes
  
: AFAIK, besides cower, packer [http://kmkeen.com/multithreaded-bash/] and bauerbill ({{ic|download.sh}} amongst others) have multiple threads. aurutils also uses aria2c for downloads, if that counts.
+
Similar to the ''Diff view'' column. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:32, 4 July 2018 (UTC)
: The benefits of multiple threads are however not always clear:
 
:: * by my understanding, cower uses multiple threads, but with one query per package [https://github.com/falconindy/cower/blob/master/cower.c#L667] (compare against multiinfo).
 
:: * More generally, tasks (like dependency solving) can be sped up by using different methods which need to be called less often
 
:: * Building packages would almost always be done sequentially: dependencies have to be installed (resulting in pacman locks), and there's {{ic|-j}} in {{ic|makepkg.conf}} anyway.
 
: Regardless, there are some large differences in AUR helper speed (with bauerbill being ahead of the rest). But I'm not sure how to quantify this in the table ... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:31, 3 April 2016 (UTC)
 
  
:: Multi-thread support doesn't necessarily mean the helper is better. In cower case, multi-thread support was implemented before multiinfo was available in the RPC interface, and as of today using multiinfo is less complex and faster than using multiple info threads. Since it is difficult to implement multiinfo support without an important rewrite, cower multithreading is more a drawback than an advantage.
+
: good idea, you also mentioned this for aurman a few months ago, see: https://github.com/polygamma/aurman/issues/25#issuecomment-371971155 really a good idea to implement it in a way, so that changes of all known files are being shown [[User:Polygamma|Polygamma]] ([[User talk:Polygamma|talk]]) 17:07, 4 July 2018 (UTC)
:: As for speed, it's indeed very hard to quantify in a meaningful manner. For example, pacaur dependency solver is slower than bauerbill's solver, but on the other hand it is designed to compute more stuff than other helpers up front in order to avoid bothering the user once the install process is started. --[[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 13:42, 3 April 2016 (UTC)
 
  
::: Interesting. Actually, I did not want to induce a "speed" column, rather the opposite. As you both say, always very difficult to choose a fairly universal/comparable benchmark, so "speed" as such is better be left out of comparison (as a column). If one wants to mention it, it might be useful to have a general remark at the top of the table, or somewhere else in the article, quoting some of the influencing factors you name; perhaps linking to (re -j) [[Makepkg#MAKEFLAGS]] and (re Skyhawk's remark above) [[Makepkg#Improving compile times]]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 14:01, 3 April 2016 (UTC)
+
: "All files in the git repo or tar archive -> Yes" What exactly do you mean by all files? Build files often contain non text files such as images. Git diff is smart enough to hide these but then you could consider that partial because not all files are covered.
 +
: In my opinion all a helper has to do to be secure it pause and allow the user to read the build files. The helper does not even need to offer to open them for you that's the user's responsibility. Anything more than that is nice to have but not strictly needed. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 20:25, 4 July 2018 (UTC)
  
== <s>Unmaintained Aur Helpers</s> ==
+
:: If this qualifies as "nice to have", there has to be an explicit warning that a green entry in the "Secure" column does not cover other files, files which may cause more harm than the PKGBUILD itself (such as {{ic|.install}} files or exectuables called from the PKGBUILD). In either case it's misleading, since you either give the impression that viewing PKGBUILDs alone is sufficient (with the current criteria), or include a warning that diminguishes the value of the criteria in the first place.
 +
:: Latter is similar to "Native pacman", in that you have a warning at the article top warning against any sort of pacman wrapping, and criteria in the table that ignore this warning, or even reward behavior which goes against it. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:07, 8 July 2018 (UTC)
  
It seems my edit to adding the info about Pacaur being unmaintained was reverted. Are we not allowed to mark aur helpers as unmaintained? What is the proper way to go about letting users know that things like Pacaur are now unmaintained upstream?[https://github.com/rmarquis/pacaur] {{unsigned|19:33, 18 December 2017‎|Ase1590}}
+
::: That's a fair point, what about changing the name to "show files before sourcing" or something? Seems more accurate. Then it would make sense that not showing .install files to be partial. The only problem I see that it's not as hard hitting as "secure". [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 20:11, 8 July 2018 (UTC)
  
:Unmaintained helpers are not a big deal since helpers should only be used by people who can solve their own problems (as indicated by the warning at the top of the article). However, if you can demonstrate that a helper ''actually stops working'' in a general sense, with no community interest to fix it, you can remove them from the article. (and file a request on AUR as well) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:43, 18 December 2017 (UTC)
+
:::: It cuts both ways: it's an effective deterrent against broken helpers, but it also gives the impression that using a "Secure" helper makes usage of the AUR safe, which it definitely doesn't. I'm not sure on what different name to use, though. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:25, 14 July 2018 (UTC)
  
::I would argue that an [unmaintained] tag would be helpful for quickly finding an AUR helper instead of having to futz around on github pages to see that it has not be updated in X amount of months/years and that it has been abandoned. I agree that if an aur helper ''actually'' broke due to some update, that it would be a candidate for removal from the AUR helper page. The whole point of wiki info is for at-glance quick info, otherwise, it'd be documentation and not a wiki. [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 18:59, 18 December 2017 (UTC)
+
::::: I guess "File view" could work. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:44, 14 July 2018 (UTC)
  
:::That brings other issues. First, you'd have to make a reasonable definition of "unmaintained". Should it be an official statement from the maintainer where he distances himself from the project? Should it be some fixed interval between commits? Should it be how upstream cares for outstanding issues? If you include the last two criteria, 90% of the AUR helpers on this page classifies as "unmaintained" and the value of the tag is lost.
+
:::::: The column name was updated to "File review". Are there remaining helpers that only display the PKGBUILD? ({{AUR|trizen}} springs to mind) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:30, 23 August 2018 (UTC)
:::Second, the "unmaintained" information would have to be continually checked to keep the page factual, which for 23 helpers in [[AUR helpers#Build and search]] alone is hardly reasonable. Especially when you as the user already has a nice table at the bottom, which narrows down your choice to 3-4 projects (entries with all the green) already. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:14, 18 December 2017 (UTC)
 
  
::::I think we can use your first definition of unmaintained as the formal definition for this page. The developer of Pacaur has made an official statement where he is distancing himself. As for the second point, the "continually checked" argument does not make sense for a wiki, as users are free to edit and update information whenever. All wiki pages can be subject to information rot, just look at some of the less common non-english pages in the arch wiki, which have in one instance in IRC displayed information about configuring arch prior to Systemd integration. Wikis stay up to date so long as other users contribute. [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 19:29, 18 December 2017 (UTC)
+
== <s>proper batch interaction 2 and 3</s> ==
  
:::::It still makes no sense to me as it punishes projects for maintainers declaring them as unmaintained. Other projects could make no such announcement and be left in a far worse state, yet as they would not be marked as "unmaintained", would be prioritized in their consideration. (which again, is not deserved) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:32, 18 December 2017 (UTC)
+
Is there even a way to implement this feature correctly?
  
:::::: I suppose we could add a softer toned tag such as [project maintainer needed] that way this instead encourages people to pick it up upstream when reading. Formally abandoned packages are going to lose support over time anyway from social media like reddit and those subscribed to the project via things like github, and it can't be helped (especially if the package outright becomes broken/incompatible). [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 19:41, 18 December 2017 (UTC)
+
I do not know much so correct me if I'm wrong but the proper way to do {{ic|2}} and {{ic|3}} for something like {{ic|wrapper repopkg aurpkg}} seemingly is:
  
::::::: That's a notion I can support. I'm not sure on the best format to add such a tag to the page. It seems out of place in the "Specificity" column of the comparison table (since it's not a feature of the project); on the other hand, it's more in plain view there and e.g. aura already mentions an aspect not strictly feature-related (the need for ArchHaskell). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:51, 18 December 2017 (UTC)
+
# copy sync db and perform sync on copied db, avoiding possible partial upgrades in the system
 +
# find {{ic|repopkg}} and {{ic|aurpkg}} using copied sync db and AUR backend respectively
 +
# {{ic|[user]}} package confirmation
 +
# get all AUR package files of {{ic|aurpkg}} and its AUR deps
 +
# {{ic|[user]}} batch inspection
 +
# loop: if new AUR deps introduced get package files for those too and do another batch inspection
 +
# calculate solutions using up-to-date copy of sync db
 +
# {{ic|[user]}} batch queue updates and resolutions
 +
# <s>sync sync db with its copy and</s> perform system upgrade
 +
## calculate solutions again with sync db (if sync db is different from its copy)
 +
## {{ic|[user]}} batch queue updates and resolutions again (if solutions are different)
 +
# perform other package operations in resolved order
 +
# build and install AUR packages in resolved order
  
:::::::: How about [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=503126&oldid=503125] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:57, 18 December 2017 (UTC)
+
-- 13:50, 26 August 2018 (UTC), last edited -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:43, 26 August 2018 (UTC)
  
::::::::: I like this, though it might look more pleasing if it were moved under the Build and Search heading at the end of the pacaur description, though that ''could'' just be my OCD just kicking in. [[User:Ase1590|Ase1590]] ([[User talk:Ase1590|talk]]) 20:06, 18 December 2017 (UTC)
+
: For 2/ the biggest pitfall to avoid  is to calculate the solution for AUR deps on the basis of completely updated repo packages, not on the basis of the currently installed packages (f.e., the way it is done in yaourt can lead to some issues. From what I've seen, all of the other helpers (aurman, pikaur, yay) have some issues in their latest iterations with 2/, though aurman does better than the rest). -- [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 14:27, 26 August 2018 (UTC)
  
:::::::::: Feel free to make the change. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:13, 18 December 2017 (UTC)
+
::I agree. Maybe it is not clear but I assumed points 1-8 have to be done with up-to-date copy of sync db, not sync db and not local db (both of which remain unchanged up to point 9). -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:08, 26 August 2018 (UTC)
  
::::::::::: After thinking about it, I think yours is best. Most attention will be focused on the table as you said earlier, so if the aim is to attract new contributers to a project then it makes most sense for it to be in the highest visibility area, which in this case is the comparison table -- 21:19, 18 December 2017‎ Ase1590
+
::: Good then. This said, your solution above seems a bit over complicated to me (f.e. points 6 that should be done in 5, or 7 that should be done before 4), but I might miss something since I have never implemented batch interaction 2/ myself - I rejected the idea because of its complexity. -- [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 09:26, 27 August 2018 (UTC)
  
== Reliable solver  ==
+
:::: Is there anything left to discuss that affects the article, or can this be closed? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:56, 18 September 2018 (UTC)
  
https://aur.archlinux.org/packages/plasma-git-meta/ have some missing dependencies:
+
:::::I think this discussion is certainly is not "solved" but it is not really about article itself but rather something to better discussed with helper developers as part of some issue or pull request. With that in mind, I'm closing this discussion. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 18:54, 18 September 2018 (UTC)
  discover-git
 
  oxygen-git
 
  
Which other package can I use to test the criteria of being a reliable solver?
+
== <s>Show which unsafe flags are used by default</s> ==
[[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 19:24, 5 February 2018 (UTC)
 
  
:Try plasma-desktop-git or ros-indigo-desktop. I tried testing it myself but couldn't since pkaur failed immediately with a python traceback. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:05, 5 February 2018 (UTC)
+
Batch interaction has the qualifier: An asterisk denotes functionality specifically enabled by the user.
  
:: `ros-indigo-desktop` failed because it depends on https://aur.archlinux.org/packages/ros-indigo-catkin/ which depends on `python2-catkin-pkg` (which provided by https://aur.archlinux.org/packages/python2-catkin_pkg/). However AUR RPC seems to be not supports search by Provides field:
+
The unsafe flags column should also do this to show what is and is not enabled by default.
:: https://aur.archlinux.org/rpc/?v=5&type=search&arg=python2-catkin-pkg&by=name-desc
 
:: https://aur.archlinux.org/rpc/?v=5&type=info&arg[]=python2-catkin-pkg
 
  
:: For `plasma-desktop-git` i've got dependencies resolved (hopefully correctly):
+
There's also other solution's such as "-Sy (enabled by --foo)", but that would probably make the column annoyingly long. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]])
:: https://imgur.com/a/9dA5S however it's gonna build for month or so on my hardware. Mb there is some way to reproduce it with some simpler example? [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 19:24, 5 February 2018 (UTC)
 
  
::: Also could you please upload the traceback somewhere? It's probably unrelated to resolving but still will be useful for me. [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 19:32, 5 February 2018 (UTC)
+
: See [https://wiki.archlinux.org/index.php/User_talk:Svito/AUR_helpers#unsafe_flags_column_position]. -- [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 09:20, 27 August 2018 (UTC)
  
::::[https://paste.xinu.at/Kn7s/] [https://paste.xinu.at/w7Gud/] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:23, 6 February 2018 (UTC)
+
::In short, 1. I didn't like how asterisks or "optional" looked 2. it's arguably not very important anyway. Open to suggestions though, as long as it's reasonable in terms of column length (see the discussion above on small screens). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:00, 27 August 2018 (UTC)
  
::::: thanks! and what is the output of `file /var/lib/pacman/sync/custom.db`? i have idea how to fix that but
+
::: There is also the option of removing the asterisk in Batch interaction. It's even less important here than in the Unsafe flags column. -- [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 16:23, 27 August 2018 (UTC)
first i am trying to understand if .db file is always gzip or its format could vary
 
  
::::: also dependencies list for plasma got computed the same (in pikaur some of deps were duplicated but i've fixed that already) [[User:Actionless|Actionless]] ([[User talk:Actionless|talk]]) 21:14, 6 February 2018 (UTC)
+
::::[[Special:Diff/538051/538105|Another option]] is to merge both columns and indicate what unsafe flags used for what. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 22:57, 27 August 2018 (UTC)
 +
 
 +
:::::IDK, looks messy to me, besides that unsafe flags are not necessarily linked to batch interaction (e.g., pacman -Ud). For my part I don't mind removing the "optional"/asterisks altogether and just let the user click the myriad of links we've provided. (Not sure what happened to the links in the ''batch interaction'' column) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:01, 27 August 2018 (UTC)
 +
 
 +
::::::I tried again with just asterisks, br tags and no commas [[Special:Diff/538110/538120|here]]. I think we should have "optional" notation in those 2 columns as it was considered an improvement when helper has made this behaviour optional and not default and scored higher in the table. It sounds to me like a considerable detail to have documented. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 01:57, 28 August 2018 (UTC)
 +
 
 +
:::::::As far as I'm concerned, optional behavior in the unsafe flags column does not have to influence ranking anymore. All technical considerations aside, some authors have adopted optional flags not because they agreed with this practice, but because the AUR helper article is treated as some kind of religious object.
 +
:::::::It's easier to assume that any pacman wrapper is broken by design - as hinted to by the warning - and use the unsafe flags as an enumeration of known problematic behavior. This is again similar to [[AUR helper#Graphical]]. That said, I have no real objections against [[Special:Diff/538110/538120]] either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 07:22, 28 August 2018 (UTC)
 +
 
 +
::::::::Merged with [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=538151&oldid=538003]. That leaves the alphabetical sorting. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 07:48, 28 August 2018 (UTC)
 +
 
 +
:::::::::I am worried with how powerful this article have become in affecting popular opinion, [[User:Kitsunyan|Kitsunyan]] may get too much of user feedback of kind yay or aurman authors have received so far possibly by being in that forever cursed top spot, and for sole author of pakku that may be too much to handle. yay is probably better fit to be in top position for now in my opinion. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 09:44, 28 August 2018 (UTC)
 +
 
 +
::::::::::I guess we can wait until aura v2.0 is released. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:00, 28 August 2018 (UTC)
 +
 
 +
:::::::::::Closing, pakku can use more testing as recent commits attest, and yay is the most popular AUR package now anyway. (I was never fond of artificially modifying the article due to poor user behavior anyway) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:04, 21 September 2018 (UTC)
 +
 
 +
:::::::: Yes, fully agree. I'm also pretty sure some of the optional flags will change as default in the not-so distant future. The asterisks look fine, I guess the important point was to remove the colours, as frankly that is what is decisive for user choice. Helper users are a very simple beast... Lastly, thanks to both of you and anyone else involved for that deep rework. -- [[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 09:56, 28 August 2018 (UTC)
 +
 
 +
== Pacman wrappers Specificity ==
 +
 
 +
I wanted to introduce the ''manual AUR package selection'' specificity for pacman wrappers. For example '''yay''' and '''pakku''' only allow {{ic|-Syu}} where they update system packages and AUR packages at the same time. '''pikaur''' when doing {{ic|-Syu}} also updates system packages and AUR packages at the same time but prompt user for manual selection for AUR packages, because for example I want to update to the new version of X program but not the Y lib (AUR) that is used only by Z program (AUR) so until Z is not updated I don't want to update Y. And '''yaourt''' when doing {{ic|-Syu}} updates only system packages, {{ic|-Syu --aur}} is needed for updating AUR packages as well, and a manual selection for AUR packages is available. That's why I wanted to introduce the ''manual AUR package selection'' specificity. -- [[User:Noraj|Noraj]] ([[User talk:Noraj|talk]]) 11:16, 9 September 2018 (UTC)
 +
 
 +
:Why just not specify {{ic|--ignore ''ylib''}}? It is problem with ''zprogram'' if it does not use versioned deps and allows library update that breaks it. Helper should just fail to satisfy AUR deps in correct case, bail out and user should specify {{ic|--ignore}} manually explicitly IMO.
 +
:Additionally '''yay''' asks you what AUR packages to not upgrade that also provides solution to this [[w:XY problem|XY problem]].
 +
:All-in-all if you can no longer build some package from AUR correctly because of dependency update that package is broken and should be fixed or be removed instead. And helpers should ideally not provide workarounds for problems that broken package introduce.
 +
:-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 13:06, 9 September 2018 (UTC)
 +
 
 +
::It's not really about broken programs. It could just as easily apply to some package that you're sure will compile fine, but you also remember takes 45 minutes to build, which you don't want to spend right now.
 +
 
 +
::Also I really don't consider using versioned deps, to be the correct case. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 14:45, 9 September 2018 (UTC)
 +
 
 +
:::That's exactly my use case. Whether to allow it as a specificity or not? I'd probably say sure. But I also think there should be a cap on how many specificities an entry may have. I'd say max 4 or 5, otherwise the column may as well be called feature list. [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 14:57, 9 September 2018 (UTC)
 +
 
 +
== Baseline AUR helper features ==
 +
 
 +
Some proposals about section names:
 +
* ''Search-only'' -> ''Fetch only''
 +
* ''Build and search'' -> ''Fetch and build''
 +
* change introduction sentence
 +
** from: Most helpers automate the process of retrieving a package's [[PKGBUILD]] from the AUR and building the package.
 +
** to: AUR helpers provide functionality of searching for packages in [[AUR]] and fetching their [[PKGBUILD]]s. Some helpers additionally automate build and install process.
 +
 
 +
Also about {{AUR|package-query}}. I can't check now because github is down but if it does not retrieve PKGBUILDs (judging from ''N/A'' under ''Git clone'' column) shouldn't it be under ''Libraries''? Why does it qualify as AUR helper?
 +
 
 +
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:04, 11 September 2018 (UTC)
 +
 
 +
:The recent move to [[Pacman/Tips and tricks]] is absurd. When AUR automation is not considered, as it is everywhere in the wiki ''but'' [[AUR helpers]], {{ic|package-query}} offers no benefit over existing tools like {{ic|expac}}. This is in to contrast {{ic|repoctl}} which contains non-trivial local repository functionality, and has some AUR support as a secondary feature. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:55, 13 September 2018 (UTC)
 +
 
 +
::I reverted my last mess-ups. I don't understand what I'm doing lately so I'm taking a break. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 23:01, 13 September 2018 (UTC)
 +
 
 +
:Renames I like, although {{AUR|package-query}} is truly search only. The points in the intro are definitely better, the grammar is a little messed up though.
 +
:{{AUR|package-query}} Works as a command line tool. Libraries would be #included or the language's equivalent.
 +
: [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 21:15, 11 September 2018 (UTC)
 +
 
 +
::I suppose one could call it a forking bash library if one really wanted. Like expac, it's really only particularly useful as a printf-style formatting parser for the package database, except that package-query merges this with the AUR's json RPC interface. It may not be a library in terms of C programming usage semantics, but terms of the intent behind its usage it very much is a library tool.
 +
::I guess the same could be said of coreutils tools like cut, join, expr, tsort, etc.
 +
::Ha, someday when I Make Yaourt Great Again™ I should also make package-query a dual shared library/PIE ''and'' a bash loadable builtin. Gotta be more libraryish in order to avoid those expensive forks, yo. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 03:48, 12 September 2018 (UTC)
 +
 
 +
:Please review [[Special:Diff/540990]], [[Special:Diff/540997]]. Additionally section changes:
 +
:* ''Search-only'' -> ''Search and fetch''
 +
:** {{AUR|package-query}} specificity -> "search only"
 +
:* ''Build and search'' -> ''Fetch and build''
 +
:-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 19:11, 18 September 2018 (UTC)
 +
 
 +
::By that definition ("helpers that fetch"), package-query could be included in the official repositories, which I'd say is a highly unlikely event. I'm mostly neutral on the rest, though grammar should be checked and "fetch" is perhaps not the most formal term. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:46, 20 September 2018 (UTC)
 +
 
 +
== <s>Use definition list for legend</s> ==
 +
 
 +
They are the correct semantic HTML element to use and the bold styling of the definition terms makes the list more readable. Demo:
 +
 
 +
;File review: Does not [[source]] the PKGBUILD at all by default; or, alerts the user and offers the opportunity to inspect the PKGBUILD manually before it is sourced. Some helpers are known to source PKGBUILDs before the user can inspect them, '''allowing malicious code to be executed'''. ''Optional'' means that there is a command line flag or configuration option to prevent the automatic sourcing before viewing.
 +
;Diff view: Ability to view package differences on inspection. Besides the PKGBUILD, this includes changes to files such as {{ic|.install}} or {{ic|.patch}} files.
 +
;Git clone: Uses {{man|1|git-clone}} by default to retrieve build files from the AUR.
 +
;Reliable parser: Ability to handle complex packages by using the provided metadata (RPC/.SRCINFO) instead of PKGBUILD [[w:Parsing#Parser|parsing]], such as {{AUR|aws-cli-git}}.
 +
;Reliable solver: Ability to correctly solve and build complex dependency chains, such as {{AUR|ros-lunar-desktop}}.
 +
;Split packages: Ability to correctly build and install:
 +
:* Multiple packages from the same package base, without rebuilding or reinstalling multiple times, such as {{AUR|clion}}
 +
:* Split packages which depend on a package from the same package base, such as {{AUR|libc++}} and {{AUR|libc++abi}}.
 +
:* Split packages independently, such as {{AUR|python-pyalsaaudio}} and {{AUR|python2-pyalsaaudio}}.
 +
;Clean build: Does not export new variables that can prevent a successful build process.
 +
;Batch interaction: Ability to prompt before the build process, in particular:
 +
:# Inspection of package files or their differences;
 +
:# Summary of package upgrades;
 +
:# Resolution of package conflicts and installations.
 +
:An asterisk denotes functionality specifically enabled by the user.
 +
;Shell completion: [[w:Command-line_completion|Tab completion]] is available for the listed [[shell]]s.
 +
 
 +
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 04:40, 14 September 2018 (UTC)
 +
 
 +
:+1 -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:51, 14 September 2018 (UTC)
 +
 
 +
:Since the terms are not part of the first sentence of the definition anymore, they should all start with a capital letter. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:21, 15 September 2018 (UTC)
 +
 
 +
::I updated my demo. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 06:07, 17 September 2018 (UTC)
 +
 
 +
:::Merged, thank you. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:54, 18 September 2018 (UTC)
 +
 
 +
== Drop "Clean Build" Column ==
 +
 
 +
Literally every helper apart from yaourt has this as yes. Perhaps yaourt's variable exporting should be listed under specificity or the "Unsafe Flags" column could be adjusted to unsafe actions? [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 04:54, 14 September 2018 (UTC)
 +
 
 +
:Disagree, since it's a reminder to anyone writing (existing and new) helpers. Example: [https://github.com/AladW/aurutils/pull/448] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:52, 14 September 2018 (UTC)
 +
 
 +
== New test cases for dependency resolution ==
 +
 
 +
ros-foo-desktop-meta have always been difficult to build, even more so with KDE4 libs moved to AUR (see arch-dev-public). Besides the sheer number of dependencies, they otherwise have little interesting properties either.
 +
 
 +
I propose to instead use various cross-compilation packages as test cases, e.g. {{AUR|mingw-w64-zlib}} and {{AUR|powerpc-linux-gnu-gcc}}. These appear very efficient at exposing problems with complex dependency algorithms (see for example [https://github.com/Jguer/yay/issues/695] or ''aurman'''s issues with {{AUR|nsis}}) and don't take 2 years to build either. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:34, 14 September 2018 (UTC)
 +
 
 +
:We could also add some simpler cases, like {{AUR|fortune-mod-all-en}}, and add details similar to the ''Split packages'' description. That way, all existing entries with "Yes" in ''Reliable solver'' would at minimum have "Partial". -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:01, 14 September 2018 (UTC)
 +
 
 +
:I believe the mingw stuff has a bunch of circular dependencies and a bootstrapping process. Do you think AUR helper's should be expected to handle this? [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 15:25, 14 September 2018 (UTC)
 +
 
 +
:: No, I don't think so. There will always be cases that can only be dealt reasonably manually, simply because the involved complexity in implementation isn't worth it. See also related sicussion [[Talk:AUR_helpers#.22Reference.22_implementation]] above, where a set of fixed reference packages would be better than live packages. No idea how to dealt with than without a local AUR instance though. -[[User:Spyhawk|Spyhawk]] ([[User talk:Spyhawk|talk]]) 10:42, 15 September 2018 (UTC)
 +
 
 +
::: The mingw packages haven't had cycles in (global) depends for a while. As such, {{ic|makepkg -r}} works fine for these packages without manual intervention or "bootstrapping". If helpers fail, it may be because of handling split depends contrary to PKGBUILD(5), or other flaws in their dependency algorithms. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 10:05, 18 September 2018 (UTC)

Latest revision as of 10:51, 21 September 2018

"Reference" implementation

This is an alternative to #Reliable Updater. Instead of an arbitrary set of test packages, we could write up a "specification" on what a reliable AUR helper should do. This should also be more helpful for potential AUR helper writers who otherwise have to wade through complex, fully-featured AUR helpers.

I propose a minimal reference implementation with the following points:

  • No client-side workarounds for upstream limitations. In particular, a reference implementation does not need to score full points on split packages, as makepkg --pkg was removed with pacman 5.
  • Minimal language constructs in e.g. a scripting language like dash.
  • Prefer simplicity of implementation over being fully featured. In particular, an implementation may only support git clone and not git diff.

My initial plan was to keep such an implementation in a man page aurhelper(7) (hosted as part of aurutils), but we can consider including on a sub-page of this article. It could be then linked from the comparison table. Thoughts? -- Alad (talk) 13:28, 8 March 2018 (UTC)

Generally agree with the idea, but I don't think there is a way around a set of PKGBUILDs that could be used to test helpers in a local AUR instance. F.e., I wouldn't define a "reliable" helper that doesn't handle split packages well. Since helpers are tolerated rather than supported, upstream limitations of the AUR might be temporary or permanent, meaning the limitation would actually be in the helper itself (f.e. like regex support). Also, I'd use pseudo code for such a reference as the actual implementation itself doesn't matter, unless you'd like to write a new minimalist helper. Spyhawk (talk) 15:26, 8 March 2018 (UTC)
Apart from FS#56602, I can't think of a case where upstream opposed removing limitations, even if helpers directly benefited. cf. the regex support discussed in [1] or the exit codes finally introduced in makepkg 5.1 which made automatic building significantly easier imo. To me it seems that the main reason we have these AUR limations is due to the minimal interest of helper writers in contributing upstream, and upstream itself having different priorities. Not sure why former is the case, the PHP codebase may play part in it - at least it does for me.
You can keep dash close enough to pseudo-code, I guess less so if you want a complete example rather than exemplary code blocks. For the PKGBUILD set, I use this: [2] -- Alad (talk) 18:34, 8 March 2018 (UTC)
My understanding is that changes that aren't invasive will be accepted upstream, but otherwise might be rejected (see [3]). One prominent example that comes to mind is FS#48796. It's not really relevant anymore since x86 has been officially dropped, but the solution would involve duplicating DB tables on the server, which isn't trivial to implement/migrate. Many of the feature requests involve non-trivial code change, which is the main reason nobody pushed patches; I dislike PHP but the language itself isn't too hard either. For regex, see the bottom of [4], which is the follow-up of your link above.
Your testsuite seems interesting (thanks for the link), but one advantage of having a fixed set of packages is that these packages might be updated and change, making these edge cases difficult to test. This happened quite a few times with my own list of test packages in the past and this was rather annoying. Spyhawk (talk) 20:20, 8 March 2018 (UTC)

Expand Secure criteria to include other (non-PKGBUILD) bundled files

[5], in particular [6]

The new criteria would be as follows:

  • PKGBUILD, no other files -> Partial
  • Other subset of files that includes the PKGBUILD -> Partial
  • No PKGBUILD -> No
  • All files in the git repo or tar archive -> Yes

Similar to the Diff view column. -- Alad (talk) 16:32, 4 July 2018 (UTC)

good idea, you also mentioned this for aurman a few months ago, see: https://github.com/polygamma/aurman/issues/25#issuecomment-371971155 really a good idea to implement it in a way, so that changes of all known files are being shown Polygamma (talk) 17:07, 4 July 2018 (UTC)
"All files in the git repo or tar archive -> Yes" What exactly do you mean by all files? Build files often contain non text files such as images. Git diff is smart enough to hide these but then you could consider that partial because not all files are covered.
In my opinion all a helper has to do to be secure it pause and allow the user to read the build files. The helper does not even need to offer to open them for you that's the user's responsibility. Anything more than that is nice to have but not strictly needed. Morganamilo (talk) 20:25, 4 July 2018 (UTC)
If this qualifies as "nice to have", there has to be an explicit warning that a green entry in the "Secure" column does not cover other files, files which may cause more harm than the PKGBUILD itself (such as .install files or exectuables called from the PKGBUILD). In either case it's misleading, since you either give the impression that viewing PKGBUILDs alone is sufficient (with the current criteria), or include a warning that diminguishes the value of the criteria in the first place.
Latter is similar to "Native pacman", in that you have a warning at the article top warning against any sort of pacman wrapping, and criteria in the table that ignore this warning, or even reward behavior which goes against it. -- Alad (talk) 17:07, 8 July 2018 (UTC)
That's a fair point, what about changing the name to "show files before sourcing" or something? Seems more accurate. Then it would make sense that not showing .install files to be partial. The only problem I see that it's not as hard hitting as "secure". Morganamilo (talk) 20:11, 8 July 2018 (UTC)
It cuts both ways: it's an effective deterrent against broken helpers, but it also gives the impression that using a "Secure" helper makes usage of the AUR safe, which it definitely doesn't. I'm not sure on what different name to use, though. -- Alad (talk) 17:25, 14 July 2018 (UTC)
I guess "File view" could work. -- Alad (talk) 17:44, 14 July 2018 (UTC)
The column name was updated to "File review". Are there remaining helpers that only display the PKGBUILD? (trizenAUR springs to mind) -- Alad (talk) 15:30, 23 August 2018 (UTC)

proper batch interaction 2 and 3

Is there even a way to implement this feature correctly?

I do not know much so correct me if I'm wrong but the proper way to do 2 and 3 for something like wrapper repopkg aurpkg seemingly is:

  1. copy sync db and perform sync on copied db, avoiding possible partial upgrades in the system
  2. find repopkg and aurpkg using copied sync db and AUR backend respectively
  3. [user] package confirmation
  4. get all AUR package files of aurpkg and its AUR deps
  5. [user] batch inspection
  6. loop: if new AUR deps introduced get package files for those too and do another batch inspection
  7. calculate solutions using up-to-date copy of sync db
  8. [user] batch queue updates and resolutions
  9. sync sync db with its copy and perform system upgrade
    1. calculate solutions again with sync db (if sync db is different from its copy)
    2. [user] batch queue updates and resolutions again (if solutions are different)
  10. perform other package operations in resolved order
  11. build and install AUR packages in resolved order

-- 13:50, 26 August 2018 (UTC), last edited -- Svito (talk) 16:43, 26 August 2018 (UTC)

For 2/ the biggest pitfall to avoid is to calculate the solution for AUR deps on the basis of completely updated repo packages, not on the basis of the currently installed packages (f.e., the way it is done in yaourt can lead to some issues. From what I've seen, all of the other helpers (aurman, pikaur, yay) have some issues in their latest iterations with 2/, though aurman does better than the rest). -- Spyhawk (talk) 14:27, 26 August 2018 (UTC)
I agree. Maybe it is not clear but I assumed points 1-8 have to be done with up-to-date copy of sync db, not sync db and not local db (both of which remain unchanged up to point 9). -- Svito (talk) 16:08, 26 August 2018 (UTC)
Good then. This said, your solution above seems a bit over complicated to me (f.e. points 6 that should be done in 5, or 7 that should be done before 4), but I might miss something since I have never implemented batch interaction 2/ myself - I rejected the idea because of its complexity. -- Spyhawk (talk) 09:26, 27 August 2018 (UTC)
Is there anything left to discuss that affects the article, or can this be closed? -- Alad (talk) 10:56, 18 September 2018 (UTC)
I think this discussion is certainly is not "solved" but it is not really about article itself but rather something to better discussed with helper developers as part of some issue or pull request. With that in mind, I'm closing this discussion. -- Svito (talk) 18:54, 18 September 2018 (UTC)

Show which unsafe flags are used by default

Batch interaction has the qualifier: An asterisk denotes functionality specifically enabled by the user.

The unsafe flags column should also do this to show what is and is not enabled by default.

There's also other solution's such as "-Sy (enabled by --foo)", but that would probably make the column annoyingly long. Morganamilo (talk)

See [7]. -- Spyhawk (talk) 09:20, 27 August 2018 (UTC)
In short, 1. I didn't like how asterisks or "optional" looked 2. it's arguably not very important anyway. Open to suggestions though, as long as it's reasonable in terms of column length (see the discussion above on small screens). -- Alad (talk) 15:00, 27 August 2018 (UTC)
There is also the option of removing the asterisk in Batch interaction. It's even less important here than in the Unsafe flags column. -- Spyhawk (talk) 16:23, 27 August 2018 (UTC)
Another option is to merge both columns and indicate what unsafe flags used for what. -- Svito (talk) 22:57, 27 August 2018 (UTC)
IDK, looks messy to me, besides that unsafe flags are not necessarily linked to batch interaction (e.g., pacman -Ud). For my part I don't mind removing the "optional"/asterisks altogether and just let the user click the myriad of links we've provided. (Not sure what happened to the links in the batch interaction column) -- Alad (talk) 23:01, 27 August 2018 (UTC)
I tried again with just asterisks, br tags and no commas here. I think we should have "optional" notation in those 2 columns as it was considered an improvement when helper has made this behaviour optional and not default and scored higher in the table. It sounds to me like a considerable detail to have documented. -- Svito (talk) 01:57, 28 August 2018 (UTC)
As far as I'm concerned, optional behavior in the unsafe flags column does not have to influence ranking anymore. All technical considerations aside, some authors have adopted optional flags not because they agreed with this practice, but because the AUR helper article is treated as some kind of religious object.
It's easier to assume that any pacman wrapper is broken by design - as hinted to by the warning - and use the unsafe flags as an enumeration of known problematic behavior. This is again similar to AUR helper#Graphical. That said, I have no real objections against Special:Diff/538110/538120 either. -- Alad (talk) 07:22, 28 August 2018 (UTC)
Merged with [8]. That leaves the alphabetical sorting. -- Alad (talk) 07:48, 28 August 2018 (UTC)
I am worried with how powerful this article have become in affecting popular opinion, Kitsunyan may get too much of user feedback of kind yay or aurman authors have received so far possibly by being in that forever cursed top spot, and for sole author of pakku that may be too much to handle. yay is probably better fit to be in top position for now in my opinion. -- Svito (talk) 09:44, 28 August 2018 (UTC)
I guess we can wait until aura v2.0 is released. -- Alad (talk) 12:00, 28 August 2018 (UTC)
Closing, pakku can use more testing as recent commits attest, and yay is the most popular AUR package now anyway. (I was never fond of artificially modifying the article due to poor user behavior anyway) -- Alad (talk) 10:04, 21 September 2018 (UTC)
Yes, fully agree. I'm also pretty sure some of the optional flags will change as default in the not-so distant future. The asterisks look fine, I guess the important point was to remove the colours, as frankly that is what is decisive for user choice. Helper users are a very simple beast... Lastly, thanks to both of you and anyone else involved for that deep rework. -- Spyhawk (talk) 09:56, 28 August 2018 (UTC)

Pacman wrappers Specificity

I wanted to introduce the manual AUR package selection specificity for pacman wrappers. For example yay and pakku only allow -Syu where they update system packages and AUR packages at the same time. pikaur when doing -Syu also updates system packages and AUR packages at the same time but prompt user for manual selection for AUR packages, because for example I want to update to the new version of X program but not the Y lib (AUR) that is used only by Z program (AUR) so until Z is not updated I don't want to update Y. And yaourt when doing -Syu updates only system packages, -Syu --aur is needed for updating AUR packages as well, and a manual selection for AUR packages is available. That's why I wanted to introduce the manual AUR package selection specificity. -- Noraj (talk) 11:16, 9 September 2018 (UTC)

Why just not specify --ignore ylib? It is problem with zprogram if it does not use versioned deps and allows library update that breaks it. Helper should just fail to satisfy AUR deps in correct case, bail out and user should specify --ignore manually explicitly IMO.
Additionally yay asks you what AUR packages to not upgrade that also provides solution to this XY problem.
All-in-all if you can no longer build some package from AUR correctly because of dependency update that package is broken and should be fixed or be removed instead. And helpers should ideally not provide workarounds for problems that broken package introduce.
-- Svito (talk) 13:06, 9 September 2018 (UTC)
It's not really about broken programs. It could just as easily apply to some package that you're sure will compile fine, but you also remember takes 45 minutes to build, which you don't want to spend right now.
Also I really don't consider using versioned deps, to be the correct case. -- Eschwartz (talk) 14:45, 9 September 2018 (UTC)
That's exactly my use case. Whether to allow it as a specificity or not? I'd probably say sure. But I also think there should be a cap on how many specificities an entry may have. I'd say max 4 or 5, otherwise the column may as well be called feature list. Morganamilo (talk) 14:57, 9 September 2018 (UTC)

Baseline AUR helper features

Some proposals about section names:

  • Search-only -> Fetch only
  • Build and search -> Fetch and build
  • change introduction sentence
    • from: Most helpers automate the process of retrieving a package's PKGBUILD from the AUR and building the package.
    • to: AUR helpers provide functionality of searching for packages in AUR and fetching their PKGBUILDs. Some helpers additionally automate build and install process.

Also about package-queryAUR. I can't check now because github is down but if it does not retrieve PKGBUILDs (judging from N/A under Git clone column) shouldn't it be under Libraries? Why does it qualify as AUR helper?

-- Svito (talk) 16:04, 11 September 2018 (UTC)

The recent move to Pacman/Tips and tricks is absurd. When AUR automation is not considered, as it is everywhere in the wiki but AUR helpers, package-query offers no benefit over existing tools like expac. This is in to contrast repoctl which contains non-trivial local repository functionality, and has some AUR support as a secondary feature. -- Alad (talk) 14:55, 13 September 2018 (UTC)
I reverted my last mess-ups. I don't understand what I'm doing lately so I'm taking a break. -- Svito (talk) 23:01, 13 September 2018 (UTC)
Renames I like, although package-queryAUR is truly search only. The points in the intro are definitely better, the grammar is a little messed up though.
package-queryAUR Works as a command line tool. Libraries would be #included or the language's equivalent.
Morganamilo (talk) 21:15, 11 September 2018 (UTC)
I suppose one could call it a forking bash library if one really wanted. Like expac, it's really only particularly useful as a printf-style formatting parser for the package database, except that package-query merges this with the AUR's json RPC interface. It may not be a library in terms of C programming usage semantics, but terms of the intent behind its usage it very much is a library tool.
I guess the same could be said of coreutils tools like cut, join, expr, tsort, etc.
Ha, someday when I Make Yaourt Great Again™ I should also make package-query a dual shared library/PIE and a bash loadable builtin. Gotta be more libraryish in order to avoid those expensive forks, yo. -- Eschwartz (talk) 03:48, 12 September 2018 (UTC)
Please review Special:Diff/540990, Special:Diff/540997. Additionally section changes:
  • Search-only -> Search and fetch
  • Build and search -> Fetch and build
-- Svito (talk) 19:11, 18 September 2018 (UTC)
By that definition ("helpers that fetch"), package-query could be included in the official repositories, which I'd say is a highly unlikely event. I'm mostly neutral on the rest, though grammar should be checked and "fetch" is perhaps not the most formal term. -- Alad (talk) 11:46, 20 September 2018 (UTC)

Use definition list for legend

They are the correct semantic HTML element to use and the bold styling of the definition terms makes the list more readable. Demo:

File review
Does not source the PKGBUILD at all by default; or, alerts the user and offers the opportunity to inspect the PKGBUILD manually before it is sourced. Some helpers are known to source PKGBUILDs before the user can inspect them, allowing malicious code to be executed. Optional means that there is a command line flag or configuration option to prevent the automatic sourcing before viewing.
Diff view
Ability to view package differences on inspection. Besides the PKGBUILD, this includes changes to files such as .install or .patch files.
Git clone
Uses git-clone(1) by default to retrieve build files from the AUR.
Reliable parser
Ability to handle complex packages by using the provided metadata (RPC/.SRCINFO) instead of PKGBUILD parsing, such as aws-cli-gitAUR.
Reliable solver
Ability to correctly solve and build complex dependency chains, such as ros-lunar-desktopAUR.
Split packages
Ability to correctly build and install:
  • Multiple packages from the same package base, without rebuilding or reinstalling multiple times, such as clionAUR
  • Split packages which depend on a package from the same package base, such as libc++AUR and libc++abiAUR.
  • Split packages independently, such as python-pyalsaaudioAUR and python2-pyalsaaudioAUR.
Clean build
Does not export new variables that can prevent a successful build process.
Batch interaction
Ability to prompt before the build process, in particular:
  1. Inspection of package files or their differences;
  2. Summary of package upgrades;
  3. Resolution of package conflicts and installations.
An asterisk denotes functionality specifically enabled by the user.
Shell completion
Tab completion is available for the listed shells.

--Larivact (talk) 04:40, 14 September 2018 (UTC)

+1 -- Alad (talk) 10:51, 14 September 2018 (UTC)
Since the terms are not part of the first sentence of the definition anymore, they should all start with a capital letter. -- Lahwaacz (talk) 07:21, 15 September 2018 (UTC)
I updated my demo. --Larivact (talk) 06:07, 17 September 2018 (UTC)
Merged, thank you. -- Alad (talk) 10:54, 18 September 2018 (UTC)

Drop "Clean Build" Column

Literally every helper apart from yaourt has this as yes. Perhaps yaourt's variable exporting should be listed under specificity or the "Unsafe Flags" column could be adjusted to unsafe actions? Morganamilo (talk) 04:54, 14 September 2018 (UTC)

Disagree, since it's a reminder to anyone writing (existing and new) helpers. Example: [9] -- Alad (talk) 10:52, 14 September 2018 (UTC)

New test cases for dependency resolution

ros-foo-desktop-meta have always been difficult to build, even more so with KDE4 libs moved to AUR (see arch-dev-public). Besides the sheer number of dependencies, they otherwise have little interesting properties either.

I propose to instead use various cross-compilation packages as test cases, e.g. mingw-w64-zlibAUR and powerpc-linux-gnu-gccAUR. These appear very efficient at exposing problems with complex dependency algorithms (see for example [10] or aurman's issues with nsisAUR) and don't take 2 years to build either. -- Alad (talk) 11:34, 14 September 2018 (UTC)

We could also add some simpler cases, like fortune-mod-all-enAUR, and add details similar to the Split packages description. That way, all existing entries with "Yes" in Reliable solver would at minimum have "Partial". -- Alad (talk) 12:01, 14 September 2018 (UTC)
I believe the mingw stuff has a bunch of circular dependencies and a bootstrapping process. Do you think AUR helper's should be expected to handle this? Morganamilo (talk) 15:25, 14 September 2018 (UTC)
No, I don't think so. There will always be cases that can only be dealt reasonably manually, simply because the involved complexity in implementation isn't worth it. See also related sicussion Talk:AUR_helpers#.22Reference.22_implementation above, where a set of fixed reference packages would be better than live packages. No idea how to dealt with than without a local AUR instance though. -Spyhawk (talk) 10:42, 15 September 2018 (UTC)
The mingw packages haven't had cycles in (global) depends for a while. As such, makepkg -r works fine for these packages without manual intervention or "bootstrapping". If helpers fail, it may be because of handling split depends contrary to PKGBUILD(5), or other flaws in their dependency algorithms. -- Alad (talk) 10:05, 18 September 2018 (UTC)