[pacman-dev] pacman-disowned

[Jeremy Heiner]

On Fri, Oct 4, 2013 at 9:15 PM, Dave Reisner <d at falconindy.com> wrote:
> 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.

Hi, Dave,
Thank you for your response.

I want to clarify that I never meant to cite algorithmic similarity as
justification for this feature's inclusion within pacman. The only
justifications I have offered for this are based on the use case
analysis. I'm sorry my words were confusing. I was only referencing
the algorithms to indicate where the feature seemed best to fit so as
to maximize the potential for code reuse.

I agree that this decision is very much about the problem domain. And
I've tried to provide justification by examining the user's goal of
performing system maintenance. I would very much like to hear any
thoughts you have about that.

> 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.

My original post (sept.29) has an attachment containing my prototype.
Somehow it got marked as non-text (?) but it is just Scala source
code. Sorry, it's not documented at all. But it's perfectly obvious to
me :). I would be happy to answer any questions.

I don't think the local db structure is much of a factor because the
time reading+parsing 1 or 2 files per package is swamped by reading
the filesystem. And if you count up the filesystem accesses, this new
feature is on par with "pacman -Qk", so not that long at all.

> 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.

Note that unmanaged files may appear in non-leaf managed dirs, but
such files are not reported by this script.
Thanks again,
Jeremy