Jguer
More descriptive error message when directories exist in cachce
Is your feature request related to a problem? Please describe.
Sometimes when I update with yay I get an error along the lines of
AUR Explicit (3): zotero-6.0.30-1, slack-desktop-4.35.121-1, teams-for-linux-1.3.18-1
:: (0/3) Downloaded PKGBUILD: zotero
:: (0/3) Downloaded PKGBUILD: slack-desktop
:: (1/3) Downloaded PKGBUILD: teams-for-linux
-> error fetching zotero: fatal: destination path 'zotero' already exists and is not an empty directory.
context: exit status 128
error fetching slack-desktop: fatal: destination path 'slack-desktop' already exists and is not an empty directory.
context: exit status 128
A solution to this problem seems to be to remove the corresponding directories in the yay cache (~/.cache/yay on my machine, I assume that's the default).
Describe the solution you'd like
I think this error message would be more helpful if instead of giving only the package name as the path (eg 'zotero' above) it would show the full path. This would improve user friendliness by removing the need to know where yay clones packages or having to search the error message to find out.
Describe alternatives you've considered
Directories for lots of packages that manage to update are in the cache without problem, so my solution is just a workaround that doesn't address whatever the real issue it. If the error message could be updated to indicate the underlying problem that would be an alternative, but either way I think it would be better with more information.
I think this error message would be more helpful if instead of giving only the package name as the path (eg 'zotero' above) it would show the full path
I just looked into this issue and the error message that shows the path is actually created by git, not yay. Do you have another proposed way of inserting the cache directory into that error message that is intuitive for users?
A solution to this problem seems to be to remove the corresponding directories in the yay cache
That would work, but may not be desired by many users. Possibly a config option could be set by the user, but I can't imagine this error message happens a lot and therefore don't think it would really be worth it.
This happened to me today also, and I had to spend 15min to google and solve this. I think the only viable solution would be for yay to remove the directories, since like you say, it doesn't happen often. Is it because yay can't pickup where it left off earlier that this happens? I feel like it puts a dint in the feeling of pkg manager being reliable and able to take care of it's packages. I know yay packages aren't for the typical grandparent, but it would just be impossible for an unexperienced user to have to deal with these things. Should't our goal be that linux should be better at taking care of itself than windows? Do you have any input why anyone wouldn't like this? How about scanning the files in the folder and only remove the files that don't correspond to the version one is trying to install? It has to be an automatic solution at least, which ever one is best.
Otherwise thank you for an awesome product!
I just looked into this issue and the error message that shows the path is actually created by git, not yay. Do you have another proposed way of inserting the cache directory into that error message that is intuitive for users?
One option would be to catch this message from git and print it with the cache dir inserted.
Or, easier, would be to add a line before the git command (I guess it's git clone?) is run that tells the user what is about to happen and/or where.
Something like
Downloading source with `git clone $SOURCE_REPO $TARGET_DIR` in $PWD
A solution to this problem seems to be to remove the corresponding directories in the yay cache
By this I just meant that doing so manually solves the problem. I didn't mean to propose this as a yay-internal solution.
If you wanted to have yay "solve" this automatically I would propose again catching that error message and moving the existing cache/dir to cache/dir.bkp and printing a corresponding warning. That way the cached version is not deleted (until this happens twice).
(I put "solve" in quotes because whatever the reason this happens for some dir but not others, is not addressed.)
I don't know go but if you tell me where to look I can have a go at a PR.
The reason this happens seem to be that some software gets stuck in the cache removal due to privilege? got this message when I tried to run yay -Scc: Unable to remove /home/user/.cache/yay/mullvad-vpn: unlinkat /home/user/.cache/yay/mullvad-vpn/src/gopath/pkg/mod/golang.zx2c4.com/[email protected]/rwcancel/rwcancel.go: permission denied
Though sudo fixes that..