[pacman-dev] What to do with pacsysclean and pacsize?

[Pierre Neidhardt]

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.sh

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