[pacman-dev] pacman-disowned

[Dave Reisner]

On Fri, Oct 04, 2013 at 10:25:01AM -0400, Jeremy Heiner wrote:
> I'm using -Qkkk right now (easy hack, minimal footprint), but like the
> output format that can easily be tweaked.
> 
> One reason I keep associating this new find untracked feature with the
> existing '--check's is that they are algorithmic cousins. From the
> controller (query.c) point of view these 3 features are called in
> basically identical ways. And from the implementation (check.c) view
> they all have the same shape (for each file in list call 1 or more
> predicates). However, I'm definitely not implying that implementation
> details should dictate user interface.
> 
> But there seems to be a deeper reason. It's rooted in the use case.
> Consider what actions the user must do to achieve the goal. At a
> minimum(*) they must invoke pacman twice. Just -Qk isn't enough
> because it ignores the mtrees. And just -Qkk checks nothing for
> packages without an mtree. Am I wrong to think that adding another
> step is the wrong direction to go to help the user achieve their goal?
> 
> So I want to advocate for a solution that does all the steps in a
> single invocation. I don't want to remove the ability to run the steps
> independently. In fact, I think it makes a lot of sense for the output
> of the single invocation to be very terse, providing the 10,000 foot
> view, and the user needs to re-invoke (w/ different args) for more
> detail on any problems noted in the overview.
> 
> (*)Are there other steps that should be folded in? My brain is so down
> in the weeds of the implementation right now that I don't completely
> trust my view of the trees, much less the forest.
> 

So, I'm still not convinced that this belongs in pacman. The package
manager manages *packages* and the files that belong to them. That
they're algorithmically similar doesn't really appeal to me -- it's
about problem domain.

In addition, the local DB and the files are structured in such a way
that they're extremely inefficient at lookups of this nature. As you've
yet to post any code, output, or performance numbers, I'm going to
blindly guess that this is a *long* operation. You could, of course,
restructure the data to make it quicker to search.

I'm not against the idea in principle, but I really don't see why it
needs to be in pacman. For fun, I cobbled together the attached shell
script which eschews some accuracy for speed. I'm sure it could be
improved. Currently, it runs in 4 seconds on my machine.

Cheers,
Dave
-------------- next part --------------
#!/bin/bash

shopt -s dotglob

declare -A leafs=([/]=1)

mapfile -t dirs < <(pacman -Qlq | grep '/$' | sort)
for (( i = 0; i < ${#dirs[*]}; i++ )); do
  dir=${dirs[i]}
  parent=${dir%/*/}/

  if [[ ${leafs["$parent"]} ]]; then
    unset leafs["$parent"]
    continue
  fi

  leafs["$dir"]=1
done

files=()
for l in "${!leafs[@]}"; do
  t=("$l"*)
  [[ -e $t ]] && files+=("${t[@]}")
done

printf '%s\n' "${files[@]}" | grep -vFf <(pacman -Qlq | grep -v '/$')