[pacman-dev] [arch-dev-public] Filename search for Arch

Travis Willard travis at archlinux.org
Fri Jan 25 21:43:41 EST 2008


On Jan 25, 2008 6:40 PM, Dan McGee <dpmcgee at gmail.com> wrote:
>
> On Jan 25, 2008 5:31 PM, eliott <eliott at cactuswax.net> wrote:
> >
> > On 1/25/08, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> > > On Jan 25, 2008 5:02 PM, Thomas Bächler <thomas at archlinux.org> wrote:
> > > > eliott schrieb:
> > > > > I guess I don't see where this script fits in, and how it is supposed
> > > > > to be used.
> > > > > thomas made mention of using zgrep for advanced users, but that seems
> > > > > just as difficult as opening a web browser and typing into a search
> > > > > box.
> > > >
> > > > The purpose is to provide filelists for download, so they can be
> > > > searched offline by pacman.
> > > > My first idea (implementing an online search in pacman) was rejected,
> > > > thus I thought about a "download the filelist and search it" offline
> > > > solution.
> > >
> > > Oh, I must have misunderstood too. If you're going to implement
> > > filelist search and all that stuff, we should:
> > > a) Move this to the pacman-dev mailing list
> > > b) Add external tools to do this as part of the "pacman source", i.e.
> > > as a patch to repo-add
> > > c) Not use this script until pacman actually has this feature.
> > >
> > > If the intent is to let users zgrep it, then I agree with cactus that
> > > that is significantly more complex then actually using the website to
> > > provide a search interface.
> >
> > Yeah. I wasn't apposed to having a file search mechanism on the site.
> > I was apposed to having pacman query the website. If a user opens up a
> > browser and searches, no problem. It was tying this to pacman that I
> > felt was a *really bad idea*.
> >
> > Alternatively, if there is a pacman only solution, that involves some
> > mirrored meta in the repository, that is something else entirely, and
> > should probably be talked about on the pacman dev list, so as to make
> > it as distribution neutral as possible.
>
> As I've said already, I really don't think this feature belongs in
> pacman. Obviously you can draw the connection with the -Ql operation,
> and the fact that we have -Ss, but this is something a bit different
> than that and I see it as feature creep.

I disagree - pacman is the tool for managing local and remote
collections of packages, and knowing what files are inside what
packages certainly falls in that realm.  I don't see how this feature
is any more feature-creepish than pacman -Ql or pacman -Qo.  There've
been many valid use-cases suggested already, so it's not a fluff
request.

Maybe I'm missing something here, but I don't see what's so horrible
about including it, aside from the fact it means we need to download
more meta-info from the repos.  I've skimmed through the thread, and
haven't seen this yet, so I'll ask - can those who are opposed (Dan,
and Jeff for instance) give reasons why you think it's improper to
place this functionality inside pacman itself?




More information about the pacman-dev mailing list