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