You are not logged in.
hi, i just got thinking about this after failing to look for a package containing a particular binary (ie. basically trying to figure out which package i should -S; see http://bbs.archlinux.org/viewtopic.php?p=25647 for more info) - do u think that such a feature could be incorporated into pacman?
much like '-Qo' - but probably less 'strict' on the 'path' thing (ie. if i want to find out which packages provides the 'dig' binary, it's ok if i just specify 'dig', instead of say '/usr/bin/dig' - since i may not know the exact path) - and possibly allowing for grep patterns as well (basically just a grep anyway through the filelist).
Caveat: I recognize though, that for this change to be made, changes must be made to the info that stored in the local database as well (currently, it seems to store only rudimentary info like "depends", and a short "desc", comprising "name", "version", "desc", and "md5sum"...
what do u guys think? i think that would be a really useful feature (at least for guys who arent that familiar with the packages yet - or who want to find out if there's a package for 'such-and-such')
Offline
I'm not sure I understand, are you looking for something different from the pacman -Ss functionality?
Dusty
Offline
yes - basically, 'what package in the db provides for a binary called "dig" (for example'?
that's what i'm suggesting. 'pacman -Ss' only provides for a rudimentary search through the package /names/ themselves - and the short descriptions.
Offline
It could be done... but then we'd need a server somewhere that knew the contents of every package. As it stands, we don't have anything like that
The other thing is that -S is the only option that uses the internet (and only if it's with a -y or -u). Likely you don't want to download the list of files in packages on every db update, so pacman would be doing some real more difficult querying.
More likely you'd see a web interface so searching instead of something in pacman.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
It could be done... but then we'd need a server somewhere that knew the contents of every package.
yep!!! indeed...
As it stands, we don't have anything like that
The other thing is that -S is the only option that uses the internet (and only if it's with a -y or -u). Likely you don't want to download the list of files in packages on every db update, so pacman would be doing some real more difficult querying.
well yeah - i guess to be "efficient", this new feature would necessitate a change in the downloading "logic" for pacman... well perhaps one of these days when i am more free and am in a "hacking" mode, i will sit down with the pacman source and see what i can do. Provided u guys dont mind adding the new feature, of course.
More likely you'd see a web interface so searching instead of something in pacman.
does the web interface have what i want?
Offline
I am thinking at something like that since some time.
My problem sometime is to understand a certain file, that is not in the system, to which package belong
In this case pacman -Qo is unuseful.
I know that is impossible having ALL possible package contents in the system but this can be done for official and extra and eventually extended to all the repository that are configured in the local pacman.conf by downloading a complete database of the filelist.
But this has also a drawback. The size of the DB increase considerably. This can be partially solved by adding a unix time as identifier for the version of the repository DB (maybe is already like that), the filelist-repository DB is downloaded separatly on user command and is built having has version identifier the same timestamp repository.
In this way you can download separatly the filelist-repository DB only if you need it.
And evetually during an interrogation pacman can give a warning message like
Some of filelist-repository DB are outdated
extra has been created on 1 May 2004 12:25.24 and filelist-repository DB is of the version 25 April 2004 10:00.19
In this way the user can decide if is the case to update the filelist or not, maybe if the difference is only of 10 minutes it is not realy necessary
Offline