Difference between revisions of "Talk:AUR helpers"

From ArchWiki
Jump to navigation Jump to search
 
(75 intermediate revisions by 13 users not shown)
Line 1: Line 1:
== Expand Secure criteria to include other (non-PKGBUILD) bundled files ==
+
== Legend editions ==
  
[https://github.com/Jguer/yay/issues/493], in particular [https://github.com/Jguer/yay/issues/493#issuecomment-402522467]
+
[[Special:Diff/573543/573551]]: Good revert, I did these late into sleepless night and did not notice this were huge and not that thought through changes :/
  
The new criteria would be as follows:
+
* <s>Merge note definitions for partial and optional as part of legends list?</s> This was a mistake, note there exactly makes sense according to style rules.
* PKGBUILD, no other files -> Partial
+
* Add known used unsafe flags to legend, add that asterisk means optional, as it may be unclear?
* Other subset of files that includes the PKGBUILD -> Partial
+
* Move legend concerning pacman wrappers only inside its section? Alternatively mention these apply only to pacman wrappers, example text:
* No PKGBUILD -> No
 
* All files in the git repo or tar archive -> Yes
 
  
Similar to the ''Diff view'' column. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:32, 4 July 2018 (UTC)
+
:;Unsafe flags: Potentially harmful pacman flags that could be used by [[#pacman wrappers]].
 +
::* {{ic|--ask}} – [https://git.archlinux.org/pacman.git/commit/src/pacman?id=90e3e02 Undocumented option] to be used for testing only;
 +
::* {{ic|-Sy}} – Can lead to [[partial upgrade]];
 +
::* {{ic|-Ud}} – Skips dependency checks when installing packages.
 +
::{{Note|Asterisk means these pacman flags are optionally enabled.}}
 +
:;Batch interaction: Ability of [[#pacman wrappers]] to prompt before the build process and package transactions, in particular:
 +
::# Combined summary of repository and AUR package upgrades;
 +
::# Resolution of package conflicts and choice of providers.
  
: 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)
+
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 07:33, 22 May 2019 (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.
+
:Batch interaction isn't specific to pacman wrappers, at least not 2. The legend denotes it as a column though, which it isn't. At the same time, I'm not sure if replacing "columns" with "columns and values" is a good idea.
: 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)
+
:If we document all the unsafe flags, I would argue it's out of scope in this article and should be expanded in [[System_maintenance#Avoid_certain_pacman_commands]] instead. (Side-note: what if a regular AUR helper uses an unsafe command to e.g. install dependencies? None of the current entries do, but it's a possible scenario.) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:26, 25 May 2019 (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 {{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.  
+
::How about expanding the note:
:: 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)
+
::{{Note|
 +
::* ''Optional'' means that a feature is available, but only through a command-line argument or configuration option. ''Partial'' means that a feature is not fully implemented, or that it partially deviates from the given criteria.
 +
::* ''Batch interaction'' indicates the ability to prompt ''before'' the build process and package transactions. In particular:
 +
:::1. Combined summary of repository and AUR package upgrades;
 +
:::2. Resolution of package conflicts and choice of providers.
 +
::}}
 +
::I've looked at [[System_maintenance#Avoid_certain_pacman_commands]] again and it contains all needed detail already, apart from the --ask option which is niche (and linked from in the table where appropriate). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:02, 25 July 2019 (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". [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]]) 20:11, 8 July 2018 (UTC)
+
:::Agreed. What about the following style:
 +
::::The [[#Comparison tables]] columns have the following meaning:
 +
::::;Major feature columns:
 +
:::::*''Optional'' means that a feature is available, but only through a command-line argument or configuration option;
 +
:::::*''Partial'' means that a feature is not fully implemented, or that it partially deviates from the given criteria.
 +
::::;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'''.
 +
::::...
 +
::::;Shell completion: [[w:Command-line_completion|Tab completion]] is available for the listed [[shell]]s.
 +
::::;Specificity:
 +
:::::*''Batch interaction'' indicates the ability to prompt ''before'' the build process and package transactions. In particular:
 +
:::::# Combined summary of repository and AUR package upgrades;
 +
:::::# Resolution of package conflicts and choice of providers.
 +
:::-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 01:20, 2 December 2019 (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)
+
== Add yup to Pacman wrappers ==
  
::::: I guess "File view" could work. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:44, 14 July 2018 (UTC)
+
Links:
 +
[https://github.com/ericm/yup github] {{AUR|yup}}
  
:::::: 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)
+
Right now yup ticks every box in the 'Pacman Wrappers' table except for 'Split packages'.
 +
It has code completion working mostly in zsh and will soon support bash and fish too.
  
== <s>clean-chroot-manager under Maintenance section</s> ==
+
Pros:
I would like to add bullet point for [https://aur.archlinux.org/packages/clean-chroot-manager/ clean-chroot-manager] under the Maintenance section. Clean chroot manager has made my life much easier for building and maintaining PKGBUILDs on the AUR. I learned about the tool on the forum but it has been available for awhile. --[[User:Dmp1ce|Dmp1ce]] ([[User talk:Dmp1ce|talk]]) 15:26, 30 January 2019 (UTC)
 
  
:I saw the discussion in [[Talk:DeveloperWiki:Building_in_a_clean_chroot]], but it doesn't really belong in [[AUR helpers]] either - clean-chroot-manager has no AUR-specific functionality. Furthermore, including it in [[#Maintenance]] (to verify AUR PKGBUILDs for correctness) would prioritize it over {{Pkg|devtools}}.
+
It fetches pgp keys for you.
:Maybe you could do the following:
+
It shows the PKGBUILD before installing by default for security reasons.
{{META Box||{{App|[[DeveloperWiki:Building in a clean chroot|devtools]]|Build packages in a clean environment ([[systemd-nspawn]] container) to verify PKGBUILDs for correctness. Wrapped by {{AUR|aurutils}} and {{AUR|clean-chroot-manager}}.|https://git.archlinux.org/devtools.git/|{{Pkg|devtools}}}}
+
It shows far more relevant search results that other AUR helpers on the market.
}}
 
:-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:52, 30 January 2019 (UTC)
 
:: Thanks. I felt like the tool should be mentioned somewhere because I haven't known about it for years or any other tools for maintaining a clean environment for PKGBUILD development. At this point, I'll probably just write a blog post about how I maintain PKGBUILDs. --[[User:Dmp1ce|Dmp1ce]] ([[User talk:Dmp1ce|talk]]) 16:15, 30 January 2019 (UTC)
 
  
:: "to verify PKGBUILDs for correctness" is not the right wording because the purpose of the clean chroot is not to find errors in the PKGBUIlD itself, but to ensure that the package is built correctly, linked to correct libraries etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:45, 30 January 2019 (UTC)
+
[[User:Ericm|Ericm]] ([[User talk:Ericm|talk]]) 14:52, 21 July 2019 (UTC)
  
::: I added that at the last moment, feel free to change it to a more appropriate wording. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:11, 30 January 2019 (UTC)
+
:It's another yaourt clone - pretty sure we have enough of those in the table already. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:11, 21 July 2019 (UTC)
  
:::In truth, it does both. :) Edit looks good anyway. -- [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 23:02, 30 January 2019 (UTC)
+
:: Even though it's got tonnes of features that yaourt doesn't have? [[User:Ericm|Ericm]] ([[User talk:Ericm|talk]]) 20:40, 21 July 2019 (UTC)
  
== <s>Aurman incorrectly flagged as having a reliable dependency solver</s> ==
+
::: I would argue the splitting into "packages" is the main distinguish feature - things like an ncurses interface are superficial in my book.
 +
::: Generally speaking, most AUR helpers have turned out to be either vaporware or small variations on existing work. Some recent examples: {{AUR|aurs}}, {{AUR|baph}}, {{AUR|gutaur}}, {{AUR|ram}}, {{AUR|raur-git}}, {{AUR|simpleaur-git}}, {{AUR|vam}}. So let's wait a bit how this projects evolves before adding it to the wiki. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:56, 25 July 2019 (UTC)
  
Aurman [https://github.com/polygamma/aurman/issues/259 does not] have a reliable dependency solver, the same input can result in different outputs. The comparison table inaccurately states that it does, and should be amended. {{Unsigned|14:44, 1 February 2019‎|Dkmb}}
+
:::: Looks like it's still around after 3 months, so it could be added to the article. Would be nice if someone else than upstream tests the column entries, though. Also don't expect to have "far more relevant search" added, because that could basically mean anything. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:37, 10 September 2019 (UTC)
  
:Done [https://wiki.archlinux.org/index.php?title=AUR_helpers&diff=565451&oldid=565365], thanks -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:22, 1 February 2019 (UTC)
+
:::::Since it uses ncurses I would rather suggest to include it as TUI in #Graphical section instead. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 23:11, 1 December 2019 (UTC)
  
== Rua fails on split packages ==
+
== Update information on rua? ==
  
See https://github.com/vn971/rua/issues/21 [[User:Morganamilo|Morganamilo]] ([[User talk:Morganamilo|talk]])
+
Please update information on RUA helper. "Diff view" and "Split packages" were implemented, as per the linked issues. Also, please add "shellcheck" and "local patch application" to the list of features that the helper has. The second is most probably not unique, the first one is unique I think. [[User:Vasya|Vasya]] ([[User talk:Vasya|talk]]) 17:28, 23 August 2019 (UTC)
 +
 
 +
: To be specific on "split packages" support. I've made another manual test on the latest released version of the helper. 1. Tried to install both clion and clion-jre at the same time. RUA only builds it once (`rua install clion clion-jre`). 2. Requested to install `libc++`, it understands that it only needs to be built once but both packages are installed. 3. When trying to install python2-pyalsaaudio, rua correctly builds pkgbase python-pyalsaaudio, and then installs python2-pyalsaaudio. [[User:Vasya|Vasya]] ([[User talk:Vasya|talk]]) 11:31, 26 August 2019 (UTC)
 +
 
 +
::First request satisfied with [[Special:Diff/581029]]. Let's wait for opinion on other features. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 11:57, 26 August 2019 (UTC)
 +
 
 +
:::Thanks for actually testing this. Regarding the suggested features: running shellcheck before sourcing the PKGBUILD is trivial. I'm not sure what's meant by "local patch application" - does rua support git rebase with local commits, or does it just not undo local changes in the worktree e.g. through {{ic|git --autostash}}? -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:34, 10 September 2019 (UTC)
 +
 
 +
:::: Regarding shellcheck. It's not THAT trivial. For example, this is the output of `rua shellcheck xcalib/PKGBUILD`: https://gist.github.com/vn971/7bcbc5fc6ebf731abc8399988dfb4fef. Compare it to the output of raw `shellcheck xcalib/PKGBUILD`: https://gist.github.com/vn971/edb08becb9ed7dd558b4c8655b57adec. That being said, `rua shellcheck` is not ideal as well. For example, it will always approach $pkgname as an array, and warn on all usages of the variable that treat it as non-array.
 +
:::: Regarding patch application. It keeps your locally reviewed state in a separate branch. Whenever you're ready to merge upstream, it basically does `git merge upstream/master`. You can drop to shell and do a manual rebase as well if you want, though only merging is streamlined as a built-in action. It is also safe for e.g. aborting the installation, because, unless you manually merge upstream changes yourself, changes won't ever leak into your "accepted" state (local branch). Building without merging upstream/master is forbidden as a foolproof. [[User:Vasya|Vasya]] ([[User talk:Vasya|talk]]) 16:12, 12 September 2019 (UTC)
 +
 
 +
== <s>pacaur is also discontinued</s> ==
 +
 
 +
According to the project github and discussion on archlinux forum pacaur is discontinued [[User:C13251|C13251]] ([[User talk:C13251|talk]]) 13:14, 24 October 2019 (UTC)
 +
 
 +
: I think you are confusing the discontinued repo: https://github.com/rmarquis/pacaur with the fork: https://github.com/rmarquis/pacaur The fork seems pretty much alive. [[User:Vasya|Vasya]] ([[User talk:Vasya|talk]]) 13:29, 24 October 2019 (UTC)
 +
 
 +
::You meant https://github.com/E5ten/pacaur to be second link probably. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 00:15, 2 December 2019 (UTC)
 +
 
 +
== <s>Drop "Clean Build" Column</s> ==
 +
 
 +
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)
 +
 
 +
::Revisiting this topic, as 1. {{ic|makepkg}} related variables are listed under {{ic|ENVIRONMENT}} in {{man|8|makepkg}} and 2. custom logic that reimplements makepkg's configuration parsing (to e.g. append values such as PKGDEST) is more fragile than simply exporting these variables where required. That said, I guess there should remain some mention for {{ic|yaourt}} since it takes this idea to the literal extreme and apparently exports every single variable defined in {{ic|makepkg.conf}}. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:08, 1 December 2019 (UTC)
 +
 
 +
:::And I had already removed both the column and yaourt. I must be living in the past. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:13, 1 December 2019 (UTC)

Latest revision as of 01:20, 2 December 2019

Legend editions

Special:Diff/573543/573551: Good revert, I did these late into sleepless night and did not notice this were huge and not that thought through changes :/

  • Merge note definitions for partial and optional as part of legends list? This was a mistake, note there exactly makes sense according to style rules.
  • Add known used unsafe flags to legend, add that asterisk means optional, as it may be unclear?
  • Move legend concerning pacman wrappers only inside its section? Alternatively mention these apply only to pacman wrappers, example text:
Unsafe flags
Potentially harmful pacman flags that could be used by #pacman wrappers.
Note: Asterisk means these pacman flags are optionally enabled.
Batch interaction
Ability of #pacman wrappers to prompt before the build process and package transactions, in particular:
  1. Combined summary of repository and AUR package upgrades;
  2. Resolution of package conflicts and choice of providers.

-- Svito (talk) 07:33, 22 May 2019 (UTC)

Batch interaction isn't specific to pacman wrappers, at least not 2. The legend denotes it as a column though, which it isn't. At the same time, I'm not sure if replacing "columns" with "columns and values" is a good idea.
If we document all the unsafe flags, I would argue it's out of scope in this article and should be expanded in System_maintenance#Avoid_certain_pacman_commands instead. (Side-note: what if a regular AUR helper uses an unsafe command to e.g. install dependencies? None of the current entries do, but it's a possible scenario.) -- Alad (talk) 13:26, 25 May 2019 (UTC)
How about expanding the note:
Note:
  • Optional means that a feature is available, but only through a command-line argument or configuration option. Partial means that a feature is not fully implemented, or that it partially deviates from the given criteria.
  • Batch interaction indicates the ability to prompt before the build process and package transactions. In particular:
1. Combined summary of repository and AUR package upgrades;
2. Resolution of package conflicts and choice of providers.
I've looked at System_maintenance#Avoid_certain_pacman_commands again and it contains all needed detail already, apart from the --ask option which is niche (and linked from in the table where appropriate). -- Alad (talk) 22:02, 25 July 2019 (UTC)
Agreed. What about the following style:
The #Comparison tables columns have the following meaning:
Major feature columns
  • Optional means that a feature is available, but only through a command-line argument or configuration option;
  • Partial means that a feature is not fully implemented, or that it partially deviates from the given criteria.
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.
...
Shell completion
Tab completion is available for the listed shells.
Specificity
  • Batch interaction indicates the ability to prompt before the build process and package transactions. In particular:
  1. Combined summary of repository and AUR package upgrades;
  2. Resolution of package conflicts and choice of providers.
-- Svito (talk) 01:20, 2 December 2019 (UTC)

Add yup to Pacman wrappers

Links: github yupAUR

Right now yup ticks every box in the 'Pacman Wrappers' table except for 'Split packages'. It has code completion working mostly in zsh and will soon support bash and fish too.

Pros:

It fetches pgp keys for you. It shows the PKGBUILD before installing by default for security reasons. It shows far more relevant search results that other AUR helpers on the market.

Ericm (talk) 14:52, 21 July 2019 (UTC)

It's another yaourt clone - pretty sure we have enough of those in the table already. -- Alad (talk) 20:11, 21 July 2019 (UTC)
Even though it's got tonnes of features that yaourt doesn't have? Ericm (talk) 20:40, 21 July 2019 (UTC)
I would argue the splitting into "packages" is the main distinguish feature - things like an ncurses interface are superficial in my book.
Generally speaking, most AUR helpers have turned out to be either vaporware or small variations on existing work. Some recent examples: aursAUR, baphAUR, gutaurAUR, ramAUR, raur-gitAUR, simpleaur-gitAUR, vamAUR. So let's wait a bit how this projects evolves before adding it to the wiki. -- Alad (talk) 21:56, 25 July 2019 (UTC)
Looks like it's still around after 3 months, so it could be added to the article. Would be nice if someone else than upstream tests the column entries, though. Also don't expect to have "far more relevant search" added, because that could basically mean anything. -- Alad (talk) 11:37, 10 September 2019 (UTC)
Since it uses ncurses I would rather suggest to include it as TUI in #Graphical section instead. -- Svito (talk) 23:11, 1 December 2019 (UTC)

Update information on rua?

Please update information on RUA helper. "Diff view" and "Split packages" were implemented, as per the linked issues. Also, please add "shellcheck" and "local patch application" to the list of features that the helper has. The second is most probably not unique, the first one is unique I think. Vasya (talk) 17:28, 23 August 2019 (UTC)

To be specific on "split packages" support. I've made another manual test on the latest released version of the helper. 1. Tried to install both clion and clion-jre at the same time. RUA only builds it once (`rua install clion clion-jre`). 2. Requested to install `libc++`, it understands that it only needs to be built once but both packages are installed. 3. When trying to install python2-pyalsaaudio, rua correctly builds pkgbase python-pyalsaaudio, and then installs python2-pyalsaaudio. Vasya (talk) 11:31, 26 August 2019 (UTC)
First request satisfied with Special:Diff/581029. Let's wait for opinion on other features. -- Svito (talk) 11:57, 26 August 2019 (UTC)
Thanks for actually testing this. Regarding the suggested features: running shellcheck before sourcing the PKGBUILD is trivial. I'm not sure what's meant by "local patch application" - does rua support git rebase with local commits, or does it just not undo local changes in the worktree e.g. through git --autostash? -- Alad (talk) 11:34, 10 September 2019 (UTC)
Regarding shellcheck. It's not THAT trivial. For example, this is the output of `rua shellcheck xcalib/PKGBUILD`: https://gist.github.com/vn971/7bcbc5fc6ebf731abc8399988dfb4fef. Compare it to the output of raw `shellcheck xcalib/PKGBUILD`: https://gist.github.com/vn971/edb08becb9ed7dd558b4c8655b57adec. That being said, `rua shellcheck` is not ideal as well. For example, it will always approach $pkgname as an array, and warn on all usages of the variable that treat it as non-array.
Regarding patch application. It keeps your locally reviewed state in a separate branch. Whenever you're ready to merge upstream, it basically does `git merge upstream/master`. You can drop to shell and do a manual rebase as well if you want, though only merging is streamlined as a built-in action. It is also safe for e.g. aborting the installation, because, unless you manually merge upstream changes yourself, changes won't ever leak into your "accepted" state (local branch). Building without merging upstream/master is forbidden as a foolproof. Vasya (talk) 16:12, 12 September 2019 (UTC)

pacaur is also discontinued

According to the project github and discussion on archlinux forum pacaur is discontinued C13251 (talk) 13:14, 24 October 2019 (UTC)

I think you are confusing the discontinued repo: https://github.com/rmarquis/pacaur with the fork: https://github.com/rmarquis/pacaur The fork seems pretty much alive. Vasya (talk) 13:29, 24 October 2019 (UTC)
You meant https://github.com/E5ten/pacaur to be second link probably. -- Svito (talk) 00:15, 2 December 2019 (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: [1] -- Alad (talk) 10:52, 14 September 2018 (UTC)
Revisiting this topic, as 1. makepkg related variables are listed under ENVIRONMENT in makepkg(8) and 2. custom logic that reimplements makepkg's configuration parsing (to e.g. append values such as PKGDEST) is more fragile than simply exporting these variables where required. That said, I guess there should remain some mention for yaourt since it takes this idea to the literal extreme and apparently exports every single variable defined in makepkg.conf. -- Alad (talk) 21:08, 1 December 2019 (UTC)
And I had already removed both the column and yaourt. I must be living in the past. -- Alad (talk) 21:13, 1 December 2019 (UTC)