[pacman-dev] pacman-disowned

[Dave Reisner]

On Sat, Oct 05, 2013 at 08:03:43AM -0400, Jeremy Heiner wrote:
> 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.

We're getting a bit into the abstract here. Pacman is just *one* of the
tools used as part of maintaining a system. You surely wouldn't propose
that we merge functionality into pacman that allows it to do full system
backups, fsck devices, or scrub raid arrays. I think it's equally
strange that you'd propose that pacman directly deal with the files that
it knows the least about.

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

The fact that there's now 2 concise implementations which take little
from pacman itself is fairly solid evidence that this belongs in
contrib.

> 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

Hence my comment about eschewing accuracy for speed...