Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.

FS#4824 - pacman packages remote file search

Attached to Project: Pacman
Opened by Alessio Bolognino (mOLOk) - Thursday, 15 June 2006, 11:53 GMT
Last edited by Xavier (shining) - Saturday, 03 October 2009, 16:54 GMT
Task Type Feature Request
Category Backend/Core
Status Closed
Assigned To Aaron Griffin (phrakture)
Dan McGee (toofishes)
Architecture All
Severity Low
Priority Normal
Reported Version 3.0.6
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 9
Private No


I think that should be nice to be able to search for the package
that owns a file on the ftp server (like apt-file does on debian).
In my opinion is the only lack of pacman.
The server could have a file obtained concatening all the
$ tar tfz $package.pkg.tar.gz | egrep -v '{.PKGINFO|.FILELIST)'
or something similar.
with this file will be easy to write script to handle the search
or include the feature in pacman.
This task depends upon

Closed by  Xavier (shining)
Saturday, 03 October 2009, 16:54 GMT
Reason for closing:  Implemented
Additional comments about closing:  you can use pkgfiles from pkgtools
Comment by Mildred (mildred) - Monday, 19 February 2007, 13:13 GMT
what's the status of this task ? Does someone is working on it ?
I used a lot this feature when I had Mandr(ake/iva) / Ubuntu so I wouls really like to be able to use it with ArchLinux.

It is very useful for example when you search for some peculiar binary file and you don't know in which package it is. For example yesteday I wanted to install uudecode but it was not easy to discover that is was in the sharutils package. The same thing happen for many programs.
With a such feature you would just have to grep the output for "bin/uudecode". And that's all.
Comment by Roman Kyrylych (Romashka) - Monday, 19 February 2007, 13:19 GMT
I think this will be easier to implement in web interface than in pacman.
Comment by Aaron Griffin (phrakture) - Monday, 19 February 2007, 16:15 GMT
This is fairly complicated to implement with the current way pacman is set up. It *will* be worked on, just not yet.
Comment by Łukasz (teZeriusz) - Saturday, 19 May 2007, 00:02 GMT
any progress or ideas?
Comment by Alessio Bolognino (mOLOk) - Saturday, 19 May 2007, 00:19 GMT
I just realized that gensync could simply store in the repo db the .FILELISTs created by makepkg. In this way the server shouldn't do anything.
I guess the smarter of you already thought about that but I'm not that smart :)
Anyway, the "hard thing" is to make pacman search into that files, something like pacman -Qo, but for synced repos.
Comment by Roman Kyrylych (Romashka) - Saturday, 19 May 2007, 11:42 GMT
This way db will be much larger, so it will be better to keep .FILELISTs in a separate db(s) that could be downloaded when calling something like -So.
Comment by Aaron Griffin (phrakture) - Sunday, 20 May 2007, 08:31 GMT
Yeah, the DBs increase *significantly* with files added to them. The best idea so far is Roman's, but it still seems odd, we'd need some form of -Sy for a secondary DB download as well, which would make it a fairly complex operation - either that, or make huge DBs.

I don't know of a really clean way to implement this... if anyone can give me a good idea that is simplistic in nature, I will implement it, but at this moment it seems as though all of these ideas are not that great.
Comment by Łukasz Fibinger (lucke) - Saturday, 25 August 2007, 15:23 GMT
I'm _fairly_ sure Frugalware's pacman has had such functionality (noticed that when installing F. on friend's box).
Comment by Mildred (mildred) - Wednesday, 07 November 2007, 01:46 GMT
Another option would be to download the package FILELIST only when pacman -So is called. Nothing downloaded when syncing the database.

Or add an option to pacman.conf to enable this feature. When enabled, it would download the FILELIST file from the server (separate from the current database, so the download could be separate).
Comment by Xavier (shining) - Wednesday, 20 February 2008, 18:31 GMT
Just for the record, a discussion about remote file search happened in arch-dev-public one month ago :
Not easy to sum up with the conflicting points of view..
Comment by Nagy Gabor (combo) - Thursday, 28 February 2008, 13:13 GMT
IMHO the acceptable compromise:
Store 2 db files for each repo on servers: extra.min.db.tar.gz and extra.full.tar.gz.
* min would be the default (-y) : KISS way
* full can be downloaded on request (-ya): feature-rich way (files + maybe changelog, see also: FS#9530)

As it was discussed many times, apart from files and changelog these dbs would be equivalent, and only small code modification is needed on client-side (in pacman) and on the server side (generate the full db too, with files and changelog) to implement it.
Comment by Xavier (shining) - Monday, 18 August 2008, 09:25 GMT
This was implemented 3 months ago with this script :;a=blob_plain;f=cron-jobs/createFileLists;hb=HEAD

Now every mirror has a $repo.files.tar.gz next to its $repo.db.tar.gz, for each $repo.

Here is for example one script making use of it :
Comment by Nagy Gabor (combo) - Monday, 18 August 2008, 10:57 GMT
Wow, this is great.

What about using a full repo.fulldb.tar.gz (with desc, depends, files) and repo.db.tar.gz (without files) database, and make repoext configurable in pacman.conf (db.tar.gz versus fulldb.tar.gz) maybe for each repo, making db.tar.gz the default.
Comment by Xavier (shining) - Monday, 18 August 2008, 11:02 GMT
There is already a working implementation in place for 3 months.
What is wrong with it? Why changing something that works?

And I don't see any real benefits of your method, only one drawbacks which is that all desc,depends are duplicated (present in both repo.fulldb.tar.gz and repo.db.tar.gz)
Comment by Nagy Gabor (combo) - Monday, 18 August 2008, 11:46 GMT
"What is wrong with it?"
You won, my main reason was: it is "nicer" and it is (would have been) easier to implement (repo.files.tar.gz is in database format). And personally I could hardly follow new and new scripts.

Or if you have files in sync db, you can do fileconflict test before downloading (I know, this is not implemented. See also
Comment by Gavin Bisesi (Daenyth) - Thursday, 28 August 2008, 15:07 GMT
Just to let you know, pkgfile (part of pkgtools) provides this behavior.
Comment by Xavier (shining) - Saturday, 03 October 2009, 10:43 GMT
Shall we close this now ?

Or do we still want to incorporate the generation of file db in repo-add ?
Comment by Gavin Bisesi (Daenyth) - Saturday, 03 October 2009, 16:11 GMT
There's already an FR open for the file db from repo-add, so this can probably be closed
Comment by Xavier (shining) - Saturday, 03 October 2009, 16:53 GMT
Right, that was  FS#11302