[pacman-dev] pacman-disowned

[Ashley Whetter]

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