Arch Linux

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.

I think this will be easier to implement in web interface than in pacman.

This is fairly complicated to implement with the current way pacman is set up. It *will* be worked on, just not yet.

any progress or ideas?

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.

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.

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.

I'm _fairly_ sure Frugalware's pacman has had such functionality (noticed that when installing F. on friend's box).

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).

Just for the record, a discussion about remote file search happened in arch-dev-public one month ago :
http://www.archlinux.org/pipermail/arch-dev-public/2008-January/004358.html
Not easy to sum up with the conflicting points of view..

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.

This was implemented 3 months ago with this script :
http://projects.archlinux.org/?p=dbscripts.git;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 :
http://aur.archlinux.org/packages.php?ID=17941
http://aur.archlinux.org/packages/pkgtools/pkgtools/pkgfile

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.

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)

"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 trans001.py).

Just to let you know, pkgfile (part of pkgtools) provides this behavior.

Shall we close this now ?

Or do we still want to incorporate the generation of file db in repo-add ?

There's already an FR open for the file db from repo-add, so this can probably be closed

Right, that was  FS#11302