On Sat, Oct 05, 2013 at 08:03:43AM -0400, Jeremy Heiner wrote: > On Fri, Oct 4, 2013 at 9:15 PM, Dave Reisner <[email protected]> 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...
