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