Yay: Combining -Sy and -Su

[Morganamilo]

Currently doing yay -Syu does

pacman -Sy
dependency resolving + checking + upgrade menu
pacman -Su
AUR update

I like this because it gives full batch interaction and dependency checking.

Other AUR helpers, namely Pacaur because I'm familiar with the process do something like:

pacman -Syu
dependency resolving + checking + upgrade menu
AUR update

Now there's a number of reasons I don't like this approach. Firstly if there's going to be a conflict or dependency failure between an AUR and repo package, this is not going to be detectable until after the repo update finishes.

The other point is batch interaction. First you have to answer Pacman's questions, conflicts, replaces, ect. Then wait for the update to finish, then start the AUR questions, PKGBUILD viewing, ect. To me this does not qualify as batch interaction although it seems it meets the wiki's criteria.

While do I prefer Yay's current approach I have spoken to people who dislike it, even if it is due to the "This might lead to partial updates" reasoning that I think is invalid. So I think it would be ideal to have a config option between these methods.

Probably something along the lines of --[no]combinedupgrade.

@aladw I've written no code but as I'm envisioning the current codebase It would be easiest to combine -Syu but still separate -Sy on -Ss/Si. Just due to that's the way it already is. Given that using -Sy with -Ss/Si gives potential to partial upgrades no matter what. Could Yay have a yes for native pacman while keeping that split?

[Morganamilo]

Thinking over it more I can probably scratch the last point. Should be easy to always combine -Sy* and only split -u when the config setting is set.

[AladW]

-Sys/-Syi is a thing? o_O

If yes, that would count as a partial upgrade specified by the user imo.

[Jguer]

I still don't like pacaur's approach, for the fact that you're most likely to backtrack work on the pacman -Syu than doing it right on the first try.

That and having a, for lack of a better parallelism, full overview of the map at the beginning always makes me favour the separate actions.

[Morganamilo]

-Sys/-Syi is a thing? o_O

Funny, you can do -Sys and -Syi but pacman refuses -Syc which is kinda funny.

I know all of these are a bad idea, but I like to wrap all of pacmans options. Good and bad.

[AladW]

I still don't like pacaur's approach, for the fact that you're most likely to backtrack work on the pacman -Syu than doing it right on the first try.

The relevant question is, how much effort does it add on your end to support both options? As said I only think the case -u with -Sy is relevant, anything else is the user's problem.

If it needs a drastic restructure or you want to keep the current default, I think the issue could be closed with little worry. The wiki already says that yellow entries are deviations "in minor ways" and anyone can make up their own mind on the matter by clicking on the discussion linked from the table.

[AladW]

Besides, this is the sort of thing you get from being all green on the wiki: https://github.com/polygamma/aurman/issues/140

[Morganamilo]

I still have not actually written any code as I'm waiting for a new release. But in theory basically none. I plan to simply move the -y into part of the -Syu. Yay's upgrade menu and dep checking will be unaware of this. They will still handle repo packages, it will just happen that the number of repo packages will always be 0 because an upgrade just happened.

[Morganamilo]

Besides, this is the sort of thing you get from being all green on the wiki: polygamma/aurman#140

I read that soon after it was made, as well as some of the funnier AUR comments.

But don't worry @Jguer is listed as maintainer in the PKGBUILD and it's his repo, so he can take all the flak while I enjoy the chaos :^)

[Jguer]

It's not all bad, this is an email I got some time ago that really gives you a smile when you get home at 8PM.

Thank you for building YAY, I've now replaced yaourt on all my boxes
with your app. It just works so much better in every way. Less user
prompts when building packages and runs faster too. The stats provided
by -Ps are very handy as well.

Thanks you!
A fellow Arch user
<Privacy Protected>

I enjoy Morganamilo refactoring all of the code every 2 weeks :smile:, always keeps the repo fresh and when filepath is broken, I'm the first to rain misery upon @Morganamilo :smiling_imp:.

Being all green is not a part of yay's core features so if it's done, yay :roll_eyes:, if it's not meh, works on my machine.

I still have not actually written any code as I'm waiting for a new release

I'm just waiting for the diff and edit to be done, I'm too busy to clearly stop and think about it but if you implement it I'll pop out a release as soon as it's stable.

[Morganamilo]

Naw that email is really nice, I love stuff seeing stuff like that.

The goal of each refactor is to fix slightly more than I break, so far I think it's going okay.

I'm just waiting for the diff and edit to be done, I'm too busy to clearly stop and think about it but if you implement it I'll pop out a release as soon as it's stable.

Not implying I'm waiting on you. I don't like to code unless I have an idea of how I want something to work. So for now I'm simply ignoring it until I think of a nice way to do it or somebody else does it.

Foe example I opened https://github.com/mikkeloscar/gopkgbuild/issues/15 in Feb and only now formulated everything through to start working on it.

(Not implying I'm going to take months for this though)

[Jguer]

So for now I'm simply ignoring it until I think of a nice way to do it or somebody else does it.

My type of code :laughing: , fair enough. Right now the current release is stable, it works, no critical fix is needed to build <insert obscure package that one guy uses on AUR and is maintained by another guy who never read the packaging guidelines and forgot he maintained that package> so no hurries

[AladW]

insert obscure package that one guy uses on AUR and is maintained by another guy who never read the packaging guidelines and forgot he maintained that package

Isn't that the main reason why AUR helpers are still being worked on? :smile:

[Morganamilo]

Besides, this is the sort of thing you get from being all green on the wiki: polygamma/aurman#140

I hope all of this causes aurutils to be on top. Can't wait to read the bug report aurutils -S package does not work. :P

[AladW]

Actually... the other day I saw some script that ran aurutils -Sy. It "wrapped" 20 or so helpers by copy pasting the same arguments to all of them. o_O

[Morganamilo]

@AladW But now somebody is suggesting aurutils -S https://www.reddit.com/r/archlinux/comments/8tb4wh/the_best_aur_helpers_to_replace_yaourt/