[arch-dev-public] Filename search for Arch

[Aaron Griffin]

On Jan 23, 2008 2:19 PM, Travis Willard <travis at archlinux.org> wrote:
>
> On Jan 23, 2008 3:11 PM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> >
> > On Jan 23, 2008 2:00 PM, Jeff Mickey <jeff at archlinux.org> wrote:
> > > I agree with everything eliott has said except:
> > >
> > > On Jan 23, 2008 2:32 PM, eliott <eliott at cactuswax.net> wrote:
> > > > 3. Why would someone need to search to see what owns a file that they
> > > > don't have on their system, with pacman?
> > >
> > > My favorite case for this is when I build something from source and
> > > either I don't look up or don't know the dependencies of the app.  It
> > > spits out some linking error about some library file.  Wouldn't be
> > > awesome if I could just pacman -So /lib/libyourmother.so.hot and it
> > > spit out that I was looking for extra/your-mother?  This is just one
> > > very simple example.  Not to mention it'll also help someone who has
> > > something that needs to be recompiled, because they can run pacman -So
> > > /lib/yourmother.so.hot.3 and see that it isn't in any up to date
> > > packages.
> > >
> > > The current scenario is me asking someone else to search on THEIR
> > > system for it, or searching google to find a relevant piece of
> > > software and then figure out of arch has that piece of software.  Not
> > > awesome.
> > >
> > > I think this is a useful feature IF implemented as phrakture states,
> > > which is merely throwing around filelists that are compressed on the
> > > mirrors.  For people who don't want to download it, they shouldn't be
> > > forced to.
> >
> > After talking to cactus on jabber, he pointed out the fact that the
> > critical phrase in that sentence is "with pacman". It appears that the
> > common case for looking up library names and things like that is
> > related to *building* packages and software, and as such, might fit
> > better as a supplementary tool to makepkg (or even in devtools).
>
> For looking up library names, yes.  There are other cases though -
> when (for example) glxgears and glxinfo moved into their own package
> (mesa-apps) tons of people were asking where they went.  Even I didn't
> know for a while.
>
> There's already the uudecode example provided earlier.
>
> And which package is kde-app-X located inside?  kdm?  I don't know.
>
> In any case, there are valid use cases for this feature that don't
> necessarily include building packages.

Ah thanks, these examples help too. I honestly have never needed
something like -So, so I don't know the use cases