Affected Version

yay v11.1.0 - libalpm v13.0.1

Describe the bug

When performing an action with sync (-S), the following message occurs:

response decoding failed: invalid character '<' looking for beginning of value

Doing a different action, such as -Q, completes normally.

Reproduction Steps

1. yay -Syu
2. Normal packages that are accessible from pacman are downloaded and installed normally.
3. Error message is printed when yay then attempts to work with AUR packages

Expected behavior

yay doesn't crash.

Output

$ yay -Syu
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
:: Starting full system upgrade...
 there is nothing to do
:: Searching databases for updates...
:: Searching AUR for updates...
 -> response decoding failed: invalid character '<' looking for beginning of value

$ yay -Pg
{
	"aururl": "https://aur.archlinux.org",
	"buildDir": "/home/cameron/.cache/yay",
	"editor": "",
	"editorflags": "",
	"makepkgbin": "makepkg",
	"makepkgconf": "",
	"pacmanbin": "pacman",
	"pacmanconf": "/etc/pacman.conf",
	"redownload": "no",
	"rebuild": "no",
	"answerclean": "",
	"answerdiff": "",
	"answeredit": "",
	"answerupgrade": "",
	"gitbin": "git",
	"gpgbin": "gpg",
	"gpgflags": "",
	"mflags": "",
	"sortby": "votes",
	"searchby": "name-desc",
	"gitflags": "",
	"removemake": "ask",
	"sudobin": "sudo",
	"sudoflags": "",
	"requestsplitn": 150,
	"completionrefreshtime": 7,
	"bottomup": true,
	"sudoloop": false,
	"timeupdate": false,
	"devel": false,
	"cleanAfter": false,
	"provides": true,
	"pgpfetch": true,
	"upgrademenu": true,
	"cleanmenu": true,
	"diffmenu": true,
	"editmenu": false,
	"combinedupgrade": false,
	"useask": false,
	"batchinstall": false,
	"singlelineresults": false
}

Reimplementation of config using the ini package and maps

TODO:

• [x] Remove the save system
• [x] Decide a yay.conf to package by default /etc/yay.conf
• [x] Reimplement -Pd and -Pg
• [x] To achieve a new system where to add a new config option all you need to do is add it to defaultSettings move all keys to lowercase and use that to parse yay.conf and the command-line options, this will rename some cli options.
• [ ] Man page writing
• [ ] Update completions
• [x] Add warning for users who still have yay.json

To debate:

• Removal of some underused flags from config and cli like --timeupdate and maybe --nogitclone

Hi! First off, I would like to thank you for the amazing work and effort you put into yay. It makes managing AUR packages a breeze!

I'm interested in replacing sudo with doas (a leaner alternative to sudo) on my system, but right now yay-bin is the only program that explicitly depends on sudo and effectively makes the move impossible; unless I keep both sudo and doas. I find that that would defeat the purpose of choosing a more minimal program, however.

Would it be possible for yay to support doas too? Or maybe even better to allow the user to set the program used to gain root privileges via an option in the config file, just in case a third alternative to sudo pops up in the future. That would avoid hard-coding the program used directly in yay's source code.

Affected Version

yay v8.992

Issue

Doesn't check for dependencies after editing PKGBUILD

Steps to reproduce

1. yay -S a package from AUR which has a dependency that isn't listed in it's PKGBUILD
2. add missing dependecy to PKGBUILD when prompted to (--editmenu has been enabled)
3. Checking buildtime dependencies...
4. ERROR: Could not resolve all dependencies

Expected behaviour

checks for dependencies after editing PKGBUILD recursively until satisfied.

The package I encountered this with is appmenu-qt5-git which depends on qt5-x11extras

This issue is to centralise all problems and progress on the new install algorithm. The prior pull requests can be seen here #105 #107 and should be read as some of the know problems are outlined there in detail.

Formatting and printing to the user should be discussed separately in #109 .

If there is a major bug in the install or you wish to discuss a problem in detail a separate issue should be opened. This issue is for general discussion and bug reporting.

Testing

If you are willing to test you can either test against the master branch or any open pull requests if there are any. If doing the latter you should comment on the pull request instead of here.

My testing is usually preformed in a clean chroot with only base and base-devel installed as to pull in as many dependencies as possible during each operation. This really helps in spotting missing or incorrect dependency solving.

I will be opening another issue #110 to keep track of difficult to install packages and packages which currently do not install correctly.

Status

• [x] Reliable solver of complex dependencies

• Nothing has been found yet so I'm amusing this is working

• ~~As far as i know the following issues are fixed but more testing it needed to tick this box.~~

• ~~This is mostly the case, we still miss some dependencies when dealing with packages that are pulled using its provides instead of its package name.~~

• ~~This can be seen when installing discord and the dependency tree tries to pull libjpeg provided by libjpeg-turbo~~

• [x] Split packages

• ~~Split packages are currently all or nothing. Yay will always install every package generated by a split package. If two packages foo and bar from the same pkgbase base are specified, Yay in an attempt to build foo will build base, install foo and bar then in an attempt to install bar, will rebuild base and reinstall foo and bar.~~

• ~~This can be seen when installing discord and the dependency tree pulls libc++abi and libc++.~~

• [x] Circular dependencies

• ~~After realising packages wont even build without their dependencies installed I'm not supporting circular dependencies and marking this as solved.~~

• Don't seem to be a problem for repo packages, I am currently unaware of any AUR packages with circular dependencies.

• [x] Versioned dependancies ~~- Checked by goalpm for repo packages. Currently ignored for AUR packages.~~ ~~- I am unsure whether yay should handle this, goalpm should handle this or gopkgbuild should handle this.~~

• [ ] IgnorePkg/IgnoreGroup

• Checked during sysupgrade, not during normal install.

• [ ] Respect all Pacman options (--root --dbpath --config...)

• Multiple CacheDirs is not supported

• ~~Passing an option twice but mixing long and short format e.g. pacman -s -i --info will not be respected by yay but will be respected when passed to pacman.~~

• Pretty much every option should be passed to pacman now but yay does not respect all of them.

• Siglevel is not respected in go-alpm but we always pass to pacman for installs so it shouldn't effect anything.

• HoldPkg is only used on remove and we always pass to pacman for that so we dont need to handle it.

• ~~We respect most Pacman options via alpm. Some options such as HoldPkg are Pacman specific and not part of alpm, Yay does not support these.~~

• ~~Installing packages from the AUR causes Pacman options to go unrespected due to makepkg handling this via makepkg -i and makepkg -s~~

• [ ] Make sure there are as few install transactions as possible, one call to pacman -U is preferable to multiple makepkg -i calls.

• One pacman -U is now used once per pkgBase

Use git clone for pkgbuild downloading

This is a restart of #130 given that PR has not gone anywhere and @simon04 has still not answered any of my questions related to the PR such as:

Also how does this handle migrating. If i have a package that I installed using the tarball method then switch to the git method will it handle it correctly?

I decided it was better to start over. This PR also uses some of the code from #130.

This PR in its current state is mainly for discussion on how to implement things. Currently all this PR does is replace the download method during yay -S to use git. This allows easy benchmarks, just checkout between the two versions and test for yourself.

Testing

My testing was done against ros-lunar-desktop-full which on my machine wants to download 251 Aur packages.

Time taken to download all the packages assuming none exist in cache:

• Current tarball method: 3:26
• git clone method: 1:43

If all packages in cache and up to date then Yay will not try to redownload them but if using --redownloadall then the results are as follows:

• Current tarball method: 3:26 (The same download is done, the time does not change)
• git clone Method: 1:10 (it only needs to pull instead of clone)

This shows git to actually be faster than the tarball downloads.

Features

The features I plan to implement before merging are:

• [x] Config setting for clone/tarball
• [x] Use git clone in -G for AUR ~~Use git clone in -G for ABS~~
• [x] Handle cached packages that come from tarball or git clone no matter the current config

Ideas that may be implemented:

• [ ] @ versioning: When installing AUR packages. For example yay -S yay@1e01eaf would build the package from that revision of the PKGBUILD.
• [ ] <>= versioning: Pacman already supports using these during -S to ensure the package you want fits in the range you specify. What I purpose is slightly different. Yay will find the first latest commit that matches the version you specify. So yay -S yay<4 will install the first PKGBUILD with a pkgver of less than 4.

Discussion

This PR is mostly here for discussion on how to implement certain features.

Migrating between tarball and git

My current idea of this is to only respect the config option if the cache does not already exist. If it does exist check for the .git directory. If that exists use the git method no matter the config. If it does not use tarball no matter the config.

Updating the cache

When we have a cached package and the PKGBUILD updated how should we go about pulling changes? The tarball method is simple and just unpacks the tar into whats already there. Overwriting files that exist in the tar and in cache but leaving untracked files alone.

Doing a simple git pull could cause complications if there are any user made changes. Currently this PR resets to head then pulls which will undo any user made changes. #130 uses a similar method where they fetch then reset to upsteam master. I do not know id there are any real differences between the two.

Alternatively we could just do a pull by itself. If there are merge conflicts it would be the user's job to resolve them.

Pacman wrap

using <>= behaviour different to Pacman might be frowned upon. maybe combine it with @ yay -S yay@7655bd9 yay -S yay@=3.505 yay -S yay@<4

Optimisation

This implementation is very basic, there's a couple of possible tricks that could be done to speed things up or reduce disk space but I have not tested them.

git gc Should probably be run after every pull.

--singlebranch could be used to only clone master, although most AUR packages probably only have master, I am unsure if the AUR would even allow you to push a different branch.

--depth 1 Is an obvious one but would not allow the user to then checkout specific commits if they wished to. Also possible features such as @ and <>= versioning would not work with this. It might be possible to run --depth 1 then run --unshallow when needed.

Affected Version

yay v9.1.0.r16.g808f633 - libalpm v11.0.2

Issue

Running yay -Syu --devel does not update -git packages, even after running yay -Y --gendb.

Output

➜  ~ yay -Syu --devel
[sudo] password for bucks: 
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 multilib is up to date
:: Searching databases for updates...
:: Searching AUR for updates...
:: Checking development packages...
:: Starting full system upgrade...
 there is nothing to do

The packages I am trying to update are latte-dock-git and oh-my-zsh-git. Both have had commits recently at the time of writing but yay does not detect them. Here are the two versions on my computer currently: oh-my-zsh-git r4895.c49486963-1 latte-dock-git 0.7.96.r514.gbc72c859-1 Meanwhile, the current git hashes are 52afbf77f and cf0182e82, respectively.

Fix https://github.com/Jguer/yay/issues/268

• Recursively removes unneeded dependencies
• Preserves optional dependencies by default (overridden with -cc)
• Does not list package removals, just passes them into pacman and relies on pacman confirmation dialog

After a build, sudo password is required to install the built package. However if the build takes a long time, one might miss the moment, when one needs to enter the password, resulting in a failed installation. After retrying, even without a clean build, everything gets built again, resulting in the same problem.

I saw a comment on Reddit about someone who made an alias to run curl -s https://www.archlinux.org/feeds/news/ | xmllint --xpath //item/title\ \|\ //item/pubDate /dev/stdin | sed -r -e "s:<title>([^<]*?)</title><pubDate>([^<]*?)</pubDate>:\2\t\1\n:g" before running yay -Syu to see if there are any packages that need manual intervention or have any problems. I thought it would be cool if yay automatically did this when updating. I'd make a pull request, but I know absolutely nothing about Go and even making a script that just executed ls failed for some reason. If anyone could add this (or another implementation of something similar), that would be really cool.

Also, I just wanted to say this AUR helper is really cool. Thanks to everyone who contributed to it! :)

Attempt to add a build from ABS options for official packages. Non-failing yay -S[y][u] --build [<pkg>], as long as <pkg> is an official or AUR package or there are only official & AUR packages to update.

May not be merged as is, as thorough tests are most certainly needed to make sure all cases are covered! An important point to address is the management of additional non-official repositories: as is they are silently ignored with --build option, and I don’t know how to deal with them in a tidy manner.

Any comments and hints are welcome towards improving this PR before potential merging.

Affected Version

yay v11.3.1.r73.g2bda76e - libalpm v13.0.2

Describe the bug

From using the debug option while running Yay, I noticed that Yay does not pass the --root argument to pacman when removing make dependencies. This is an issue because, when the --root argument is used, pacman installs the make dependencies to the directory provided. However, when pacman tries to remove those dependencies later on, it looks for them in the system database, not the root directory provided, which causes it to error with "target not found".

Reproduction Steps

This is a bit annoying to reproduce, but I'll try to explain it the best I can

1. First, create an executable file that passes pacman the root argument. This is needed because makepkg needs to use pacman with the --root argument. For makepkg to use this, the PACMAN env variable needs to be set. File I used:

#!/bin/bash
_pacman() {
    pacman --root "/path/to/test-root-dir" "$@"
}

_pacman "$@"

2. Next, make a clean root using mkarchroot <test-root-dir> base
3. Last, execute an AUR install with yay. I can reproduce this issue with proot. Run the command PACMAN=<path/to/pacman-executable> yay --root <path/to/test-root-dir> -S proot. Note: Make sure the removeMake option is not set to no and at least one make dependency is not already installed on the system (the example that errored for me was python-docutils). Then, watch how yay throws an error that target not found: python-docutils after running the removeMake function.

Expected behavior

The --root argument should be passed into pacman when removing make dependencies if it was passed into yay.

Output

Here is the output from yay in debug mode:

[DEBUG] running /usr/bin/sudo pacman --root /<root-dir> -D -q --asexplicit --noconfirm --config /etc/pacman.conf -- proot
[DEBUG] running /usr/bin/sudo pacman -R -u --noconfirm --config /etc/pacman.conf -- libnsl python python-docutils libxslt
error: target not found: python-docutils

Here is the relevant config:

{
    "removemake": "ask",
    "debug": "true"
}

This issue most likely persists with other global arguments besides --root.

You can see in this block that the arguments are not passed to the removeMake function. I can submit a fix for this. I think this can be solved by just passing in arguments into removeMake and adding the global arguments to the removeArguments variable in the removeMake function.

When running yay -Syu and switch to another window to work, it would be very helpful if yay prints the bell character in terminal whatever it asks for user interaction. AFAIK it has no any drawbacks.

yay cache can grow monstrously big. Would be nice to have a way to automatically clear it. Fire and forget kinda way.

I tried to make systemd service that would run yay -Sc --aur --noconfirm But that fails cuz yay can only do shit in context of a user that issus the command, I think.

Is there currently a way that one can setup where I dont have to worry about yay cache ever growing big? Consider that the space we talk about is not trivial but easily GBs with just few package installs, there should really be easy and foolproof way to just god damn do it all, no matter if there are 19 users on the system with all having their own god damn cache taking up space.. just do them all and let the devil sort them out.

considering arch itself offers this for pacman cache... with just two commands giving this functionality

• sudo pacman -S pacman-contrib
• sudo systemctl enable --now paccache.timer

Maybe aur helper should follow in similar fashion?

Is the ultimate way to just have script that deletes ~/.cache/yay for all users?

Thanks.

Is your feature request related to a problem? Please describe.

I recently realized that running yay without completing the upgrade (for example by pressing [n] when asking to upgrade) caused a partial upgrade. I do that often, for example because I realize the upgrade size is too much and I need to wait a few day to be at home

Describe the solution you'd like

I think adding a warning message would help, so users know that they are in a partial upgrade scenario and should not use yay|pacman -S. The message could tell user they just did a partial upgrade, and to upgrade their system as soon as possible. I propose to add this when the user enter [n] with yay -Syu or yay, when an error occur during the upgrade and pacman/yay exits (these two cases should be covered by the pacman exit code), and when using -Sy without u

Describe alternatives you've considered

I've considered directly asking for this feature in pacman, but I think it would be refused, because "the users should already have read the man and know how and how not to use it". yay seems more focused on user-friendliness, hence why I am asking here

Additional context

I am ready to submit a PR for this, I just would like to know if you agree with the feature first

When I use yay on a package from ABS e.g. yay -G haskell-glob I'll get

.
├── repos
│   └── community-x86_64
│       └── PKGBUILD
└── trunk
    └── PKGBUILD

I'd be satisfied with a single PKGBUILD. How do I advice yay to ignore any other sources than trunk?

The behavior of yay -Gp is great, not giving me a tree of PKGBUILDs.

Thanks in advance!