Re: prt-get functionality idea/suggestion - uninstalled port log
Hi Dark_Bakura, On 1 September 2023, dark_bakura@protonmail.com wrote:
wow, I know that I am a bit late to the reply (+year old), I had a busy year and I do not open this account often as I should :) sorry for a long delayed answer.
No need to apologize for the long delay. It's a shame the original thread didn't receive another response. With more voices weighing in, you might have been steered toward a solution that better aligns with the CRUX Mantra, rather than making prt-get "just a bit" more complex and therefore no longer simple.
Even if I am not a very skilled C++ programmer, I just wrote a patch which delete the removed package log file in /var/log/pkgbuild (if its found), doing the behavior I wrote in my email to the crux list.
I can see at least two reasons why you might have considered prt-get the natural tool to absorb your desired function: 1. Its own changelog reveals a commit that allowed prt-get to update the database of locked ports, upon removal of a package that was previously locked. You might point to that example to justify introducing another side effect of `prt-get remove`, and this argument could be made without appealing to anyone's experience doing package management on Slackware. 2. The other tool that cleans up a centralized directory (the Perl script ''oldfiles'') is specifically targeted at **pkgmk** artifacts, as evidenced by the fact that pkgmk.conf is the only global config it parses. But it requires **prt-get** to populate the central directory of build logs. Running pkgmk by hand will not put the logs into a central directory unless you redirect stderr and stdout yourself; if you do it that way, then ''oldfiles'' will have no clue what path you used to store the build logs. So in order to add this functionality to ''oldfiles'', I had to insert a routine that parses prt-get.conf, with the caveat that manual pkgmk processes might save logs in other places than what is specified by the "logfile" directive. 1+2. Seeing that automatic creation of build logs is the the consequence of orchestrating pkgmk processes through **prt-get** (while the downloads and built packages would be created no matter how you run pkgmk), the advice "clean up your own mess" would suggest delegating to prt-get any cleanup of those logs. Meanwhile **pkgmk** was always exempted from this advice (because from the beginning it expected to be paired with ''pkgadd'' and ''pkginfo'' -- or at least tar -- to do anything useful), and so companion scripts were written to provide the cleanup functionality (''prtwash'' or ''prtsweep'' when builds happen in the ports tree itself, ''oldfiles'' when central directories are used instead). Given that prt-get already accepts responsibility for "cleaning up its own mess" with respect to the locked ports database, you might naturally conclude that it should clean up its own mess with respect to build logs. If such was your thought process when you proposed this feature last year [1], I can see why you might consider it a good fit among the other features of prt-get. Arguing against this new feature in prt-get is the fact that it requires more explanation than code (at least 200 lines in the man-page and this thread, compared to less than 50 lines of C++), due to all the possible failure modes that the user must be made aware of. Note that ''oldfiles'' can incorporate your desired feature while better adhering to the principle of least surprise, because the user of ''oldfiles'' is already accustomed to post-processing the output with other tools. But by adding this feature to ''oldfiles'' we blur the line that previously demarcated whose mess ''oldfiles'' was designed to clean up. A user of this enhanced ''oldfiles'' will justifiably be confused as to which cleanup job was its primary role, and which cleanup job was tacked on later. We would be trading away some of the simplicity of prt-utils for better adherence to the principle of least surprise. I'm coming full-circle to the first reaction I had to your latest email. Namely, the tools we have are just fine as they are, and we should work on educating CRUX users how to combine them properly (FS#1410). A simple cron job, illustrated by the latest example in my expanded man-page [2], will accomplish what you asked for in your June thread last year. [1] https://lists.crux.nu/pipermail/crux/2022-June/007193.html [2] https://git.sdf.org/jmq/prt-get/src/branch/softdeps/doc/prt-get.8#L781 -- John
Hello, I like your idea too of leave the tools as they are, and give the user a hint about how can they clean up the log files if they want, with the example you provide in your repo as a hint in a man page, with can derivate to a quickly cron/script the user can implement in their system, and tunning as they want it. Thanks you kindly for your reply. samsep10l ------- Original Message ------- El martes, 5 de septiembre de 2023 a las 7:39 PM, John McQuah <jmcquah@disroot.org> escribió:
Hi Dark_Bakura,
On 1 September 2023, dark_bakura@protonmail.com wrote:
wow, I know that I am a bit late to the reply (+year old), I had a busy year and I do not open this account often as I should :) sorry for a long delayed answer.
No need to apologize for the long delay. It's a shame the original thread didn't receive another response. With more voices weighing in, you might have been steered toward a solution that better aligns with the CRUX Mantra, rather than making prt-get "just a bit" more complex and therefore no longer simple.
Even if I am not a very skilled C++ programmer, I just wrote a patch which delete the removed package log file in /var/log/pkgbuild (if its found), doing the behavior I wrote in my email to the crux list.
I can see at least two reasons why you might have considered prt-get the natural tool to absorb your desired function: 1. Its own changelog reveals a commit that allowed prt-get to update the database of locked ports, upon removal of a package that was previously locked. You might point to that example to justify introducing another side effect of `prt-get remove`, and this argument could be made without appealing to anyone's experience doing package management on Slackware.
2. The other tool that cleans up a centralized directory (the Perl script ''oldfiles'') is specifically targeted at pkgmk artifacts, as evidenced by the fact that pkgmk.conf is the only global config it parses. But it requires prt-get to populate the central directory of build logs. Running pkgmk by hand will not put the logs into a central directory unless you redirect stderr and stdout yourself; if you do it that way, then ''oldfiles'' will have no clue what path you used to store the build logs. So in order to add this functionality to ''oldfiles'', I had to insert a routine that parses prt-get.conf, with the caveat that manual pkgmk processes might save logs in other places than what is specified by the "logfile" directive.
1+2. Seeing that automatic creation of build logs is the the consequence of orchestrating pkgmk processes through prt-get (while the downloads and built packages would be created no matter how you run pkgmk), the advice "clean up your own mess" would suggest delegating to prt-get any cleanup of those logs. Meanwhile pkgmk was always exempted from this advice (because from the beginning it expected to be paired with ''pkgadd'' and ''pkginfo'' -- or at least tar -- to do anything useful), and so companion scripts were written to provide the cleanup functionality (''prtwash'' or ''prtsweep'' when builds happen in the ports tree itself, ''oldfiles'' when central directories are used instead). Given that prt-get already accepts responsibility for "cleaning up its own mess" with respect to the locked ports database, you might naturally conclude that it should clean up its own mess with respect to build logs.
If such was your thought process when you proposed this feature last year [1], I can see why you might consider it a good fit among the other features of prt-get. Arguing against this new feature in prt-get is the fact that it requires more explanation than code (at least 200 lines in the man-page and this thread, compared to less than 50 lines of C++), due to all the possible failure modes that the user must be made aware of.
Note that ''oldfiles'' can incorporate your desired feature while better adhering to the principle of least surprise, because the user of ''oldfiles'' is already accustomed to post-processing the output with other tools. But by adding this feature to ''oldfiles'' we blur the line that previously demarcated whose mess ''oldfiles'' was designed to clean up. A user of this enhanced ''oldfiles'' will justifiably be confused as to which cleanup job was its primary role, and which cleanup job was tacked on later. We would be trading away some of the simplicity of prt-utils for better adherence to the principle of least surprise.
I'm coming full-circle to the first reaction I had to your latest email. Namely, the tools we have are just fine as they are, and we should work on educating CRUX users how to combine them properly (FS#1410). A simple cron job, illustrated by the latest example in my expanded man-page [2], will accomplish what you asked for in your June thread last year.
[1] https://lists.crux.nu/pipermail/crux/2022-June/007193.html [2] https://git.sdf.org/jmq/prt-get/src/branch/softdeps/doc/prt-get.8#L781
-- John
participants (2)
-
Dark_Bakura -
John McQuah