Closed Boruch-Baum closed 8 years ago
Sorry, this is no bug. colorsvn and emacs-psv are both AUR packages and therefor only recorded in pacman.log.
I Disagree.
The user asked pamac to perform the action because pamac advertised the packages and portrayed itself to the user as the program performing the action. Users depend and expect that any important sys-admin program keep an honest, reliable, accurate, and complete record of what it does, especially since its involved in something as important as package management.
For instance, if what pamac did in this case was take a user request, and because it was an AUR package, instead of processing the request itself, passed it to pacman (unlike what it would do for non-AUR packages), then pamac could log to its own log just that: "accepted user request to -----; passed request on to pacman; received response from pacman -----.
Further, in this case, pamac went to the trouble of displaying in its visual on-screen log a set of messages that it then did not store in its own history of what users see as one indistinguishable text flow.
Please re-open the issue as a bug.
BTW, I also have reported a more serious issue, but because of its sensitivity, I sent it yesterday via private mail to "Oberon" at the manjaro project, who said he was planning on passing it to "Philip". Did it get to you? You can reach me at my gpg e-mail (short key below).
On 02/09/2016 05:49 PM, Philip Müller wrote:
Sorry, this is no bug. colorsvn and emacs-psv are both AUR packages and therefor only recorded in pacman.log.
Reply to this email directly or view it on GitHub: https://github.com/manjaro/pamac/issues/98#issuecomment-182118600
hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Well, we can go on and on with this. Pamac is using yaourt, which is using the pacman.log to record its output. Simple like that. Pamac itself uses libalpm and not pacman. Therefor we write our output into pamac.log. This is also clearly understandable that AUR is supported thru yaourt:
optdepends=('polkit-gnome: needed for authentification in Cinnamon, Gnome'
'lxsession: needed for authentification in Xfce, LXDE etc.'
'yaourt: needed for AUR support')
So I still don't get wy bother with this ...
Regarding the sudo problem, we are discussing internally.
On 02/10/2016 01:52 AM, Philip Müller wrote:
Well, we can go on and on with this I'm not trying to give you a hard time, and your further comments have given me what may be the beginning of an idea for a solution.
Pamac is using yaourt, which is using the pacman.log to record its output. So, are you saying that yaourt is directly writing to pacman.log? If so, then when pamac displayed the output messages from the two AUR install transactions, it was getting that information back from yaourt somehow, like some form of 'tee >log >STDOUT'; and if pamac can display it to the user in that scrolling text window, it should be able to route it also to pamac.log also using something like 'tee', which would be the solution. Would that be enough so when a user chooses pamac's "view history" option, s?he would see the text that pamac had just previously displayed?
Simple like that. Pamac itself uses libalpm and not pacman. Therefor we write our output into pamac.log. This is also clearly understandable that AUR is supported thru yaourt:
So I still don't get wy bother with this ... 1] Because anyone administering a system, from a personal computer to an enterprise server, [expects|deserves] [accurate|complete] logging of IMPORTANT system events, such as installation transactions.
2] Because if pamac assumes the responsibility of being the front-end both for yaourt and for pacman, and creates its own front-end logging for its operations, any reasonable user would expect that logging to be accurate and complete.
3] Because it's inconsistent to show the user a scrolling log of the transaction, and then have that transaction [not appear|disappear] from the "view history" and the log.
4] Because a gui front-end is stereo-typically intended for relative newbies and relatively unknowldgeable users, and its a bit much to expect them to take the cognitive steps: 4.1] the log is either missing or the event never happened 4.2] decide to look at the opt-depends! 4.3] correlate the AUR support to their issue 4.4] investigate how yaourt does logging It should just be in the "view history" gui window
Regards,
hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
The other solution is easier: discontinue the pamac.log completely, and do what yaourt and pacman already do - log to pacman.log. As it is, pamac.log seems to be a subset of pacman.log (I could be wrong; you're the expert), and since yaourt has already 'corrupted' pacman.log, if there's something unique for pamac to add, let it pile on.
This would also solve the "view history" aspect of the issue, because pamac could safely display the pacman.log in that window and, viola!, a complete record.
The only (major) caveat, is that this suggestion is from an outsider who isn't an expert in the internals of everything going on here.
hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
@guinux: please check if we want to record also AUR activities in our pamac.log as of now we clearly split that and the current way is proper to record all related with yaourt in pacman.log as we have now.
I created pamac.log to make a different log to know what is done with pamac. Yes, there's still a caveat with yaourt which call pacman to install built packages. I began some work to try to make yaourt call pamac to install built packages but it's complicated and I don't know yet when/if it will be implemented.
I noticed out of the corner of my eye something of possible interest flying by in the pamac cli progress window, so I used the icon on the upper right corner to "view history", and the log presented was entirely missing the recent two install requests. I then looked in /var/log/pamac.log,and it too was missing all record of those transactions performed by pamac-manager.
Surprisingly (and thankfully), /var/log/pacman.log DID record the transactions.
On the off-chance it might be helpful, the two missing recent requests were to install packages colorsvn and emacs-psvn.
I tried exiting and re-entering pamac-manager to see if it was delaying a write until close, but it didn't help.
As an aside, without knowing the internals or the historical reason for there being two separate logs, my inclination would be to prefer a single log file for both pacman and pamac. Which is the most authoritative? Do I need to constantly be checking both to know the system install history?
As for severity, 1] that will partly depend on whether pacman.log is authoritative and COMPLETE, for both pacman and pamac-*; and, 2] while for me this issue was a minor and short-lived scare (presuming pacman.log is authoritative and complete etc), for people who use pamac-manager because they are uncomfortable with the command line, and who might not know their way /var/log, this issue would be more serious.