`Native Pacman` criteria

[actionless]

(instead of passing those to class constructor)

that should allow to control the current flow of executed app from python code (not only from user's stdin input as it is now) so make it possible to interactively wrap -Syu

however in case of manual package selection ([m] choice in prompt) N reply will be sent to -Syu and -Su --ignore <interactively_ignored_package> or -Su <interactively_added_package> command will be fired depending on user choice

@AladW are the last 2 paragraphs sounding fine to you? [m] is not default behavior, so by default -Syu will be wrapped accurately

[Morganamilo]

As far as I can tell it sounds like you want to run pacman -Syu pause it after the refresh and inject your on stuff in before continuing? Is this right?

[actionless]

pacman will naturally pause while waiting for answer to :: Proceed with installation? [Y/n]

1) if user will hit 'Y' in pikaur prompt 'Y' will be just bypassed to pacman

2)

however in case of manual package selection ([m] choice in prompt) N reply will be sent to -Syu and -Su --ignore or -Su depending on user choice

[actionless]

pushed to the master. will let it some time for testing before tagging the release

[SpineEyE]

Can you please explain why you implemented this? It looks a little weird and more like a hack now compared to your previous solution of just sending a Y. More integration also generally means more maintenance work. Now the user sees the summary two times.

[actionless]

@SpineEyE you can compare pikaur-git with a stable pikaur aur package behavior to point out some particular regression issues

[actionless]

compared to your previous solution of just sending a Y

that part haven't changed at all

the only thing what changed now what instead of splitting -Syu to -Sy and -Su, the intermediate output is getting hidden (https://github.com/actionless/pikaur/blob/master/pikaur/install_cli.py#L257-L258) and the question are being shown after pikaur prompt, to be in the timeline with pikaur's questions: https://github.com/actionless/pikaur/blob/master/pikaur/install_cli.py#L253-L255

the only maintenance issue is what if pacman will change any of its messages i'll have to update them here (all in one place): https://github.com/actionless/pikaur/blob/master/pikaur/pacman.py#L48-L78 (but for sending Y i also parsing the prompts so it's not a big difference, juts couple more messages to support)

[SpineEyE]

Alright, thanks for the explanation. Then there's probably not really a better way to achieve the same minimal user interaction.

[actionless]

only with splitting Syu to Sy and Su it's possible to avoid some of the hacks, but that's generally a topic to be discussed since it's arising not only here: https://github.com/Jguer/yay/issues/464

[AladW]

Truly, I am amazed by the lengths you go to get full recognition on the table while completely ignoring the spirit behind these criteria.

That spirit being that all these helpers are completely unsupported tools with due unsupported bugs. You don't want such tools to influence the supported tools (read: pacman) in any way, be that through weird modification of IO like you do here or through adding intermediary steps like yay et al. do.

[AladW]

The sensible thing to do - as I've pointed out countless times - is to have some explicit switch so users can choose to void their Arch warranty if they so please.

[AladW]

Barring the above, please return to the old -Sy + -Su approach since that one is at least half-way predictable in what it might do, very much unlike this brittle pseudo-hook functionality you've come up with.

[actionless]

all your replies are sounding like emotions, i see no technical reasoning behind it

[actionless]

very much unlike

very good reason for removing it from arch wiki, i suppose what your emotional behavior should be reported to other arch wiki mods, it doesn't seems appropriate at all

[polygamma]

rofl.

[actionless]

Just to give an example of correct conversation style I'll try to be more technical: the possible implications are described in these tickets: https://github.com/actionless/pikaur/issues/161 https://github.com/actionless/pikaur/issues/189. There is no any danger for package database integrity. The logic which does "weird modification of IO" via sending Y character to pacman's stdin does that only for a fixed set of questions by matching full line, so if some unexpected question will be asked by pacman the stdin will be controlled by user, not by pikaur.

[Morganamilo]

The thing is, splitting -Sy and -Su is not about splitting the commands themselves, but the actions. Even though pikaur technically calls -Syu it sill effectively splits the actions.

Now while I disagree with saying overly mean things like Alad often does, he has a point. And the reason he is mad is not because of this feature unto itself but because you ignored his comments and discussion on this topic and went ahead and changed the wiki entry.

[actionless]

Even though pikaur technically calls -Syu it sill effectively splits the actions.

i am not getting this point

[SpineEyE]

Is it correct that this workaround and those painful issues that you linked, @actionless, are only necessary because there is no option to skip the first question in pacman? Wouldn't it be much less of a hassle to implement that feature there?

[actionless]

yes, that mechanism is a temporary solution to the problem you described

[actionless]

and also it is used for resolving conflicts when installing AUR-built packages, so the conflict resolution is asked from user before the build, not after the build when installing

the reason why it's better than using undocumented --ask flag of pacman because ask flag answers to "some" question, while pikspect module is expecting some particular line with the question, so the probability of unexpected behavior is less than with using --ask

[Morganamilo]

The problem is not if it's better or worse than other methods. Simply that this method still interferes with pacman by altering how it runs a command. Which means you don't meet the criteria for native pacman.

[actionless]

Simply that this method still interferes with pacman by altering how it runs a command.

could you elaborate more on how the pacman behavior is being interfered? given example of doing pikaur -Syu vs pacman -Syu or pikaur -S <repo_package_name> vs pacman -S <repo_package_name>

[Morganamilo]

I've already said you interfere between the refresh and sysupgrade. You can argue that there's nothing wrong with an AUR helper doing this. I argued this when the rules were being decided.

But the point is, the rules have been decided, the criteria set. You can argue the rules are not clear enough if you like, I'm sure Alad would be happy to modify the wiki to clarify.

[SpineEyE]

So, refering to this:

however in case of manual package selection ([m] choice in prompt) N reply will be sent to -Syu and -Su --ignore or -Su command will be fired depending on user choice

If pikaur instead sends -Syu --ignore, it should be fine?

[polygamma]

I've installed pikaur-git and ran pikaur -Syu - I got the following:

[jonny@jonny-arch-pc ~]$ pikaur -Syu
:: Starting full AUR upgrade...
Reading repository package databases...
Reading local package database...
:: Synchronizing package databases...
 core                     129.8 KiB  1396K/s 00:00 [######################] 100%
 extra                   1638.8 KiB  4.91M/s 00:00 [######################] 100%
 community                  4.4 MiB  4.69M/s 00:01 [######################] 100%
 multilib is up to date
 sublime-text is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Reading AUR packages info...                                                    
:: warning: Following packages cannot be found in AUR:
    nm-dispatcher-resolv.conf-git    

:: Repository packages will be installed:
 bluez                            5.50-2         -> 5.50-2
 bluez-libs                       5.50-2         -> 5.50-2
 json-c                           0.13-1         -> 0.13-1
 ndctl                            60.3-1         -> 60.3-1
 cryptsetup                       2.0.3-1        -> 2.0.3-1
 libraw                           0.18.11-1      -> 0.18.11-1

:: Proceed with installation? [Y/n] 
:: [v]iew package detail   [m]anually select packages
>> n

Obviously you split pacman -Syu, because -Sy is being executed, and the message :: Repository packages will be installed: is not a pacman message. btw: I've always wanted to update: bluez 5.50-2 -> 5.50-2

[actionless]

@polygamma and what your /var/log/pacman.log thinks about that?

[polygamma]

No idea what that's supposed to mean

[Morganamilo]

@SpineEyE Yes if pikaur did that it would get a green entry, although there's trade offs as I've mentioned here https://github.com/Jguer/yay/issues/464.

[actionless]

@polygamma what in pacman.log Syu is not splitted

also fixed the bug with bluez 5.50-2 -> 5.50-2

[polygamma]

What is pikaur doing?

[2018-06-11 17:58] [PACMAN] Running 'pacman --color=always --sync --sysupgrade --refresh'
[2018-06-11 17:58] [PACMAN] synchronizing package lists
[2018-06-11 17:58] [PACMAN] starting full system upgrade

after running pikaur -Syu, but BEFORE answering the question: :: Proceed with installation? [Y/n]

terminal output:

[jonny@jonny-arch-pc ~]$ pikaur -Syu
:: Starting full AUR upgrade...
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 multilib is up to date
 sublime-text is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Reading local package database...                                               
Reading repository package databases...
Reading AUR packages info...
:: warning: Following packages cannot be found in AUR:
    nm-dispatcher-resolv.conf-git    

:: Repository packages will be installed:
 bluez                            5.50-2         -> 5.50-3
 bluez-libs                       5.50-2         -> 5.50-3
 json-c                           0.13-1         -> 0.13.1-1
 libraw                           0.18.11-1      -> 0.18.12-1
 ndctl                            60.3-1         -> 60.3-2
 cryptsetup                       2.0.3-1        -> 2.0.3-2

:: Proceed with installation? [Y/n] 
:: [v]iew package detail   [m]anually select packages
>> 

Do you really stop the execution of pacman?

[actionless]

no, you would see in pacman.log if i stop it and run again

[polygamma]

what are you doing then?

[actionless]

https://github.com/actionless/pikaur/issues/201#issuecomment-394720133

[polygamma]

Okay, I see what you are doing. I have to agree with what @Morganamilo said, you are not technically splitting the command, but all in all you are achieving the same. e.g. I ran pikaur -Syu --devel, downloading the devel packages lasted on my PC ca. 10 minutes, which means there were 10 minutes between giving the "Yes" to pacman and the beginning of running "pacman -Syu".

[actionless]

which means there were 10 minutes between giving the "Yes" to pacman and the beginning of running "pacman -Syu".

and what is a problem about it? pacman db is locked all that time so nothing bad can happen to it

[polygamma]

... I am out of this discussion.

[Morganamilo]

Pikaur could crash and now you've done a refresh without an upgrade.

[actionless]

and why you convinced what other aur helpers which wrap pacman in a different way will never crash while pacman is executed? it's more like The problem is not if it's better or worse than other methods.

[Morganamilo]

Well an AUR helper would either crash before or after the pacman call, not in the middle. Anyway I think you're getting away from the point. The point is the rest of that sentence you just quoted. That's all it comes down to.

[actionless]

in aur helpers page in arch wiki it's stated as do not separate commands, command is not separated, it's a single command, pacman -Syu as you could see from pacman.log above in this thread

[Morganamilo]

To quote myself:

I've already said you interfere between the refresh and sysupgrade. You can argue that there's nothing wrong with an AUR helper doing this. I argued this when the rules were being decided.

But the point is, the rules have been decided, the criteria set. You can argue the rules are not clear enough if you like, I'm sure Alad would be happy to modify the wiki to clarify.

[actionless]

current criterias for native pacman in arch wiki are written quite explicitly and there is no way to point what any of them is currently violated, unless creating some new rules

[Morganamilo]

And to quote Alad again:

Truly, I am amazed by the lengths you go to get full recognition on the table while completely ignoring the spirit behind these criteria.

That spirit being that all these helpers are completely unsupported tools with due unsupported bugs. You don't want such tools to influence the supported tools (read: pacman) in any way, be that through weird modification of IO like you do here or through adding intermediary steps like yay et al. do.

[actionless]

i would count it if --ask flag would be prohibited as well, otherwise it's more like double-standards

[Morganamilo]

Well you're free to make your case for it on the talk page.

[actionless]

but for my case ("weird modification of IO") there is no criteria in advance denying to do it, it's again double standards

[Morganamilo]

The thing is, splitting -Sy and -Su is not about splitting the commands themselves, but the actions. Even though pikaur technically calls -Syu it sill effectively splits the actions.

I don't mind discussing this, but right now this is just going in circles with me quoting myself and others.

[polygamma]

see: https://wiki.archlinux.org/index.php/User_talk:Actionless

So far it looks like you're bug-using the leaks of arch wiki page criterias to get the better 'scores' in the table instead of putting effort into making those feature work without additional tricks with the flags.

written by @actionless

Who is "bug-using the leaks of arch wiki page criterias" now? You are not technically splitting the command, but achieving the same thing, for which the criterion exists in the first place. I said that I am out of this discussion, but I do not want to let this pass without comment.

[actionless]

i am not adding any extra flags, like your --do_everything, to get that 100% batch interaction without breaking aur helpers wiki criterias about pacman wrapping

[polygamma]

Okay, --do_everything has been added on March 7, see: https://github.com/polygamma/aurman/commit/6c02ba3db9f803f08fddf54cba390a910f7534d3 in the following context: https://github.com/polygamma/aurman/issues/23

But yeah, I am a wizard and implemented the feature, because I knew that the "100% batch interaction" was coming anytime in the future. My beard is actually much longer, but since no one should know that I am a wizard, I trimmed it for the GitHub picture.