Allow to redirect package build process into file

[diabolusss]

Similar scenario like in issue #1246. I'm currently installing webkitgtk3, and it's build process generates tons of output. And a build process takes more than an hour until it fails. It would be great to add a flag to specify the log file where to output build process and not to spam stdin.

$ yay --version yay v10.1.2 - libalpm v12.0.2

[Jguer]

Interesting idea, what would be the advantage versus a simple output redirection? How would you control which get outputted if there are multiple packages getting installed?

[diabolusss]

Sorry, but I don't know how to use simple o/p redirection with yay. Please show an example.

If you mean to redirect all messages to file, including yay, then I suppose its silent installation with no user intervention, i.e. called from script. If that's the scenario, then advantage of selective o/p is simple - the user can interact with yay, but the build process will be logged into file without spamming terminal. The log file will be useful afterwards if the build process will fail for some reason.

How would you control which get outputted if there are multiple packages getting installed?

I think it's not so important if we have a log file. Of course, it will be spammed, but it's much easier to find any information in the file than in terminal o/p. Moreover, terminal history is limited to some length, but the file size is unlimited.

[Konzertheld]

I'd like to jump in here. I've always wondered if I can keep a copy of the output yay produces. Pacman has a proper log file that contains its output - I'd like to see that for yay, too. Output redirection is not what I would like to have as that would not show the output to me while running. I would like to control / watch the process but keep a copy to check later. I could even imagine logging my user inputs.

[GameKyuubi]

How would you feel about a list of upgraded/failed packages at the end, and then separate error logs for each package, written to files linked at the ending summary? That way you don't have to scroll around to find them and you have a clear list of what isn't building without it interfering with what does build, as well as an easy-access copy of the error logs that you can peruse on your own time. Seems to cover #1126, #1246, #1548

[diabolusss]

As for me, it sounds good enough.

[Konzertheld]

How would you feel about a list of upgraded/failed packages at the end, and then separate error logs for each package, written to files linked at the ending summary? That way you don't have to scroll around to find them and you have a clear list of what isn't building without it interfering with what does build, as well as an easy-access copy of the error logs that you can peruse on your own time. Seems to cover #1126, #1246, #1548

I like that solution except that I would like to have all the logs, not only those of failed packages.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Jguer]

New logger architecture should allow to create a logging interface and use a file logger instead.

Closing, until someone wants to pick this up