On 2013-10-05 02:15, Dave Reisner wrote:
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
I agree with Dave here. I don't think this functionality is really
"core" to pacman and what it does. I do, however, think it would be a
really useful function and that therefore it should go into contrib. One
of the reasons pacman is so great is because it does a good job of
keeping the filesystem clean. But it's still a package manager, rather
than a filesystem manager.
I'm also going to argue that whatever we do here, we should do the same
with pacdiff. The reasons for this new functionality being in pacman,
contrib, whatever are likely going to be the same as pacdiff because
it's also dealing with files that aren't part of a package. In fact
pacdiff might even have more reason to go into pacman than this new
functionality because it's only dealing with files created by pacman
itself.
Ashley
