[pacman-dev] pacman-disowned

[郑文辉(Techlive Zheng)]

2013/10/5 郑文辉(Techlive Zheng) <techlivezheng at gmail.com>:
> 2013/10/4 Jeremy Heiner <scalaprotractor at gmail.com>:
>> 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.
>>
>
> Yeah, I second your propose, I used to combine `find` and `pacman -Qo`
> to accomplish this, but it is too time consuming, being able to have
> this as a built-in feature and an option would be really great.

As for the output format, anything parsable for a later processing
would be fine.