[pacman-dev] What to do with pacsysclean and pacsize?
pacsysclean is broken... In short it only looks for KiB in output to assess file size, whereas pacman now outputs the correct thing. See [1]. No-one has bothered to fix this. pacsize was submitted as a replacement [2]. It currently works, but is another tool that parses pacman output. I think we should remove pacsysclean and not add pacsize. There is expac available (and potentially being added to the pacman codebase for the next release). [I am told expac can do the same thing but I don't know how...] Opinions? [1] https://bugs.archlinux.org/task/41531 [2] https://patchwork.archlinux.org/patch/2030/
On 14-11-20 15:33:33, Allan McRae wrote:
pacsysclean is broken... In short it only looks for KiB in output to assess file size, whereas pacman now outputs the correct thing. See [1]. No-one has bothered to fix this.
pacsize was submitted as a replacement [2]. It currently works, but is another tool that parses pacman output.
I think we should remove pacsysclean and not add pacsize. There is expac available (and potentially being added to the pacman codebase for the next release). [I am told expac can do the same thing but I don't know how...]
Query local packages, display size in MB. $ expac -Q -HM '%m\t%n' Display size in KB, sort the output by size. $ expac -Q -HK '%m\t%n' | sort -n Align at the 14th column instead of using tabs. $ expac -Q -HK '%14m %n' Query DB packages. $ expac -S -HK '%m\t%n'
Opinions?
[1] https://bugs.archlinux.org/task/41531 [2] https://patchwork.archlinux.org/patch/2030/
I totally agree with your suggestion: expac could easily replace paclist, pacsysclean/pacsize, pacsearch, and probably more. It misses some features though: * Colored output. * Fallback to DB when local entry is not found. (This is basically what pacsearch is all about.) * An automatic size unit adjustment as used by pacman. I think this is more than optional. -- Pierre Neidhardt It's easier to fight for one's principles than to live up to them.
On Thu, Nov 20, 2014 at 09:33:24AM +0100, Pierre Neidhardt wrote:
On 14-11-20 15:33:33, Allan McRae wrote:
pacsysclean is broken... In short it only looks for KiB in output to assess file size, whereas pacman now outputs the correct thing. See [1]. No-one has bothered to fix this.
pacsize was submitted as a replacement [2]. It currently works, but is another tool that parses pacman output.
I think we should remove pacsysclean and not add pacsize. There is expac available (and potentially being added to the pacman codebase for the next release). [I am told expac can do the same thing but I don't know how...]
Query local packages, display size in MB. $ expac -Q -HM '%m\t%n'
Display size in KB, sort the output by size. $ expac -Q -HK '%m\t%n' | sort -n
Align at the 14th column instead of using tabs. $ expac -Q -HK '%14m %n'
Query DB packages. $ expac -S -HK '%m\t%n'
Opinions?
[1] https://bugs.archlinux.org/task/41531 [2] https://patchwork.archlinux.org/patch/2030/
I totally agree with your suggestion: expac could easily replace paclist, pacsysclean/pacsize, pacsearch, and probably more.
It misses some features though:
* Colored output.
Already supported. The format string will interpret escaped ANSI color codes. I don't see any sane way to implement default coloring.
* Fallback to DB when local entry is not found. (This is basically what pacsearch is all about.)
Such a feature would not be welcome in expac. The utility decreases in usefulness if it isn't providing exactly what the user asked for.
* An automatic size unit adjustment as used by pacman. I think this is more than optional.
Easily implemented, but I don't see the point (for similar reasons as given above). If you want to implement this, ask for bytes and apply something like to size_to_human: https://projects.archlinux.org/pacman.git/tree/scripts/library/size_to_human... dR
On 14-11-20 08:43:21, Dave Reisner wrote:
On Thu, Nov 20, 2014 at 09:33:24AM +0100, Pierre Neidhardt wrote:
On 14-11-20 15:33:33, Allan McRae wrote:
pacsysclean is broken... In short it only looks for KiB in output to assess file size, whereas pacman now outputs the correct thing. See [1]. No-one has bothered to fix this.
pacsize was submitted as a replacement [2]. It currently works, but is another tool that parses pacman output.
I think we should remove pacsysclean and not add pacsize. There is expac available (and potentially being added to the pacman codebase for the next release). [I am told expac can do the same thing but I don't know how...]
Query local packages, display size in MB. $ expac -Q -HM '%m\t%n'
Display size in KB, sort the output by size. $ expac -Q -HK '%m\t%n' | sort -n
Align at the 14th column instead of using tabs. $ expac -Q -HK '%14m %n'
Query DB packages. $ expac -S -HK '%m\t%n'
Opinions?
[1] https://bugs.archlinux.org/task/41531 [2] https://patchwork.archlinux.org/patch/2030/
I totally agree with your suggestion: expac could easily replace paclist, pacsysclean/pacsize, pacsearch, and probably more.
It misses some features though:
* Colored output.
Already supported. The format string will interpret escaped ANSI color codes. I don't see any sane way to implement default coloring.
If we can find a sane way to implement a shared coloring system, that would avoid a lot of hassle and code redundancies in scripts (which is the main topic here). pacsearch's initial goal was to combine -Qs and -Ss together + to add a colored output.
* Fallback to DB when local entry is not found. (This is basically what pacsearch is all about.)
Such a feature would not be welcome in expac. The utility decreases in usefulness if it isn't providing exactly what the user asked for.
Why wouldn't it be so? If the fallback on the DB is properly documented, then the user knows what to expect. Or to make it even more explicit, we could leave things separate as they are now and add another option for the mixed query. Calling the example of pacsearch again, its main (sole?) purpose is to combine both outputs. This is not a trivial thing to do from a user perspective and involves a lot of code duplication. Mixed queries are typically useful when both local and non-installed packages are looked-up.
* An automatic size unit adjustment as used by pacman. I think this is more than optional.
Easily implemented, but I don't see the point (for similar reasons as given above). If you want to implement this, ask for bytes and apply something like to size_to_human:
https://projects.archlinux.org/pacman.git/tree/scripts/library/size_to_human...
Sounds reasonable to me. -- Pierre Neidhardt Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
participants (3)
-
Allan McRae
-
Dave Reisner
-
Pierre Neidhardt