Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#11452 - pacman should log how it was invoked
Attached to Project:
Pacman
Opened by Carlo Bersani (carlocci) - Friday, 12 September 2008, 00:08 GMT
Last edited by Xavier (shining) - Monday, 07 September 2009, 10:53 GMT
Opened by Carlo Bersani (carlocci) - Friday, 12 September 2008, 00:08 GMT
Last edited by Xavier (shining) - Monday, 07 September 2009, 10:53 GMT
|
DetailsSummary and Info:
Pacman should log the command line through which it has been invoked. For example, instead of "starting full system upgrade", it should report "pacman -Su". This would really help logging because you would be able to recognize installation sessions, what command the user used in order to destroy his system, as well as which packages were installed as dependencies and which weren't. In this way it would be possible to restore a local database completely from a pacman.log, provided you knew what packages were installed from the install cd, or if the pacman.log from the install cd is copied to system at install time (lots of installing in this sentence). Thanks for reading. |
This task depends upon
Closed by Xavier (shining)
Monday, 07 September 2009, 10:53 GMT
Reason for closing: Implemented
Additional comments about closing: in git commit c88ac86292
Monday, 07 September 2009, 10:53 GMT
Reason for closing: Implemented
Additional comments about closing: in git commit c88ac86292
But it wouldn't be perfectly reliable though: behavior of frontends can change, switches can change meaning over the years.
Also if you would replay the log you could do lots of useless actions if the user installed packages and removed them again, especially if packages changed names, got integrated/split-up, .. etc.
So I wouldn't use it as 'backup-restore' system, but I think it would be very useful to do debugging/request help/find out why you broke your system etc.
Because I point cl_text to the location of cl_text_new and free later the cl_text
[...]
+ cl_text_new = calloc(1, cl_text_size+cl_argv_size+1);
+ memcpy(cl_text_new, cl_text, cl_text_size);
+ free(cl_text);
+ cl_text = cl_text_new;
[...]
+ free(cl_text);
[...]
ok?
Now one more query...
+ cl_text_new = calloc(1, cl_text_size+cl_argv_size+1);
[...]
+ // prevent ugly last space
+ if(cl_counter+1 < argc)
+ strncat(cl_text, " ", 1);
so on the last argument cl_text is left with an empty character slot at the end. Does this get "initialised" with garbage in C and thus might cause strange output?
Would it be better to initialise cl_text with the first arguement and then loop from 1 to cl_counter<argc, adding the space at before the argument in the loop? That would also save testing if this is the last term at each step.
Excerpt from "man 3 calloc":
calloc() allocates memory for an array of nmemb elements of size bytes each and returns a pointer to the allocated memory. The memory is set to zero. [...]