Feat aur automatic fallback

[ZorudaRinku]

Checklist

• Admin:
  • No duplicate PRs
• Integration:
  • Always add unit tests for fixes or new functionality
• Documentation:
  • If adding new options, update usage and doc/*.ronn
  • If adding new strings, update locale/*.po

Description

Add new feature; automatically falling back to AUR git downgrading when package is foreign to pacman.
Equivalent to manually passing --git --pacman-cache ~/.cache/yay --maxdepth 2 if pacman -Qm returns 0 on a package.
Automatically checks for yay and paru in their default dirs to find git repos for downgrading.

[pbrisbin]

This looks good but I'm wondering if we actually need any of these conditions / guard rails:

1. Package is foreign
2. AUR cache directory exists
3. AUR cache directory is not already given in PACMAN_CACHE

What happens if we check none of that, and simply append the conventional AUR cache directories to PACMAN_CACHE as its default value at the start of the script, then let it just run as it does?

We may need to make search_cache tolerant of missing or duplicate cache directories, but I think that would be a better use of complexity.

[ZorudaRinku]

This approach is so much simpler lol

• Had to update default maximum depth to 2, not sure if this is a huge problem but I don't think pacman has subfolders that could trip it up? But it's required for paru since they're in subdirs (~/.cache/paru/clone/packagename/)
• Updated Regex to find packages like spotify 1:1.2.79.427-2
• Auto-enabled git search since the search will show both cached builds and remote git builds (Cached on bottom)

[ZorudaRinku]

I didn't notice the --pacman-cache behavior so good call. It works as expected now (only searching the cache specified).

This does make the command a little noisy with some false errors. Find searches pacman, paru, and yay now so one will always return an error (assuming people don't install both aur and paru). We could redirect stderr again but if find runs into any other issue then we'd silence it. We could grep and redirect stderr but seems kinda messy?
find -L "${PACMAN_CACHE[@]}" -maxdepth "$DOWNGRADE_MAXDEPTH" -regextype posix-extended -regex ".*/$pkgfile_re" 2> >(grep -v 'No such file or directory' >&2)

Then search_git searches all cache dirs and throws errors for pacman and the 1 non-existent cache dir. We could just silently continue instead of outputting this warning?

❯ sudo ./downgrade spotify                                      
[sudo] password for zoruda: 
find: ‘/home/zoruda/.cache/yay’: No such file or directory
"/var/cache/pacman/pkg/spotify" not a git directory, skipping...
"/home/zoruda/.cache/yay/spotify" not a git directory, skipping...

Invalid choice --- (I rejected choices)
Unable to downgrade spotify

[pbrisbin]

This does make the command a little noisy with some false errors. Find searches pacman, paru, and yay now

Yeah, fair enough. The easiest answer may be to bring back your [[ -d checks in detect_aur_caches. I was hoping search_packages could be made tolerant of non-existent directories, but I'm now realizing that would likely require similar [[ -d checks there. If there was option to find to tell it to not warn on missing directories, that'd be ideal, but I didn't see one. I definitely don't want to silence stderr entirely.

We could just silently continue instead of outputting this warning?

I think that's what we'd want to do.

Before, git was opt-in, so if you opted in and then it wasn't a git directory you'd probably want to see this warning. I'm OK going back to that, if you'd like to keep this PR smaller for now. However, if you are going to keep this bit that automatically enables the git behavior, then we shouldn't warn for the (now expected and common) case of there being no git package.

[pbrisbin]

I'm surprised this code is wholly duplicated with ~L251, and so requires fixing twice.

Not your fault, or holding up this PR, just something I'm thinking about.

[ZorudaRinku]

Hm so already-built cache sorting now gets thrown in (seemingly) randomly instead of just being appended on the bottom like it was before... We could do some sorting to sort them back to the bottom but I would think it would be more logical to just sort them by the version so it'd show the git version above/below the cache built version if they were the same version.

Sorting them perfectly by version number seems to require some trickery with parsing the non-epoch versions from git vs cache though. And I'm not certain all the possible version numberings that can happen...:

~/.cache/paru/clone/spotify/spotify-1:1.2.77.358-1-x86_64.pkg.tar.zst - Already built in cache
~/.cache/paru/clone/spotify/spotify-1.2.77.358-7f389b0-any.gitpkg.tar.gz - From git

Thoughts?

[pbrisbin]

I would think it would be more logical to just sort them by the version so it'd show the git version above/below the cache built version if they were the same version

This makes sense to me.

perfectly by version number seems to require some trickery

I'm OK with it not being "perfect", so we can avoid trickery. But which implementation is your image showing? I would expect a sort --version-sort (which I thought we were already doing) to handle that list correctly (I see no epochs to trip it up), but it doesn't.

[ZorudaRinku]

We're sorting using pacsort but it doesn't seem handle epochs for cache built correctly. Well it does but it's as if the epoch is part of the main version number so 1:1.2 appears right next to 1.1.x but it's actually 1.2. I've been trying to figure out a way to simply/properly sort it but it's just not handled properly with pacsort.

I sorta got this but it feels a little gross. We extract the epoch prefix then sort it properly after doing so.

I also notice this is only for packages with specified epoch (I think that's how it works?) So it just happened I was testing with spotify which specify the epoch in the filename and if I try other packages it's usually not a problem anyways.

[pbrisbin]

I see about pacsort. I think using that and accepting whatever it does is the right move. If we think it's mishandling packages with epoch, that feels like a bug we could report there. I'm inclined to not care though.

[pbrisbin]

I can take over to address the conflicts and Restyled failure. I think I also want to squash merge into one feat: commit. That OK with you?

[ZorudaRinku]

Fine by me :) And yeah sorry I couldn't figure out the restyled thing lol

After thinking about this a lot more I think how I was imagining it was flipped. I don't think this is pacsorts fault, I think the problem is how we generated the list R276. Pacsort handles epochs fine, but when we were previously generating the git list we didn't include the epoch. And because I randomly decided to use spotify in testing it brought up how it was sorting poorly because of that.

I think we should include the proper sorting I committed in Epoch sorting as it should be the proper fix for this. It's just that the epoch is specified in a different variable in the pkgbuild instead of being included in the pkgver and it was just never accounted for.