JFYI: Аналогичный инструмент зовётся apt-file в Debian.

C библиотеками проблем нет - apt-get install libartsmidi.so.1 решает этот вопрос.

С остальными файлами согласен, я для этой процедуры пользуюсь grep по
content_index, что не совсем корректно для пользователя.

Список файлов частично сохраняется а частично обрезается при генерации
репозитария.  Сохраняются следующие пути: */bin/* */sbin/* */etc/* и файлы *.so
*.so.* (сохраняются ещё некоторые пути при обнаружении необходимости).

Для сохранённых путей работает 'apt-get install путь'.
В частности, заведомо работает 'apt-get install /usr/bin/что-угодно'.

Сейчас имеем
2.4M    i586/base/pkglist.classic.bz2

Предварительная оценка: если вовсе не обрезать список файлов
при генерации репозитария, то размер pkglist.classic.bz2 увеличится
примерно на 5M.  Это цена вопроса.  При каждом 'apt-get update'
придётся выкачивать на 5M больше, но зато что-то типа apt-file
сможет работать на "чистом репозитарии" без каких-либо дополнительных
данных.

Чтобы сократить размер выкачиваемого можно у дебиановского apt'а стянуть и 
адаптировать поддержку pdiff'ов.

[root@testing ~]# apt-get install docbook2html
Reading Package Lists... Done
Building Dependency Tree... Done
E: Couldn't find package docbook2html
[root@testing ~]# apt-get install /usr/bin/docbook2html
Reading Package Lists... Done
Building Dependency Tree... Done
Selecting docbook-utils for '/usr/bin/docbook2html'
The following extra packages will be installed:
  OpenSP docbook-style-dsssl docbook-utils openjade perl-SGMLSpm
The following NEW packages will be installed:
  OpenSP docbook-style-dsssl docbook-utils openjade perl-SGMLSpm
0 upgraded, 5 newly installed, 0 removed and 176 not upgraded.
Need to get 0B/1862kB of archives.
After unpacking 7594kB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.
[root@testing ~]# apt-cache search docbook2html
[root@testing ~]# 

Т.е. хотя и метод работает, но имеет несколько весомых НО:
1) Чтобы установить принадлежность файла пакету, нужно быть рутом;
2) Поиск файла методом пробной установки имхо всё же перебор;
3) Нужно знать полный путь к файлу.

Встаёт резонный вопрос: почему, если apt-get про файл знает, apt-cache молчит?
Может быть, его надо малость пропатчить на предмет большей осведомлённости? В
этом случае при сохранении размеров файлов pkglist мы получим более широкие
возможности поиска. 90% (а может и больше) запросов всё равно приходится на
файлы из /*bin/ и /usr/*bin/, а также *so*, поэтому можно бОльшую часть задачи
решить малой кровью.

Можно сделать apt-file, тягающий rsync-ом contents_index. При использовании опции -z на ALTLinux/Sisyphus/i586/base/contents_index уходит всего 5 Мб трафика.

После обновления contents_index в дело идёт grep.

(In reply to comment #7)
> Можно сделать apt-file, тягающий rsync-ом contents_index. При использовании опции -z на
> ALTLinux/Sisyphus/i586/base/contents_index уходит всего 5 Мб трафика.
Если он при обновлении будет совсем мало качать (а рсинкается он действительно быстро, когда я синкаю сизиф) - совсем здорово.

> После обновления contents_index в дело идёт grep.
А нам же надо только "в каком пакете есть файл, подходящий под такой шаблон"? Тогда всё клёво.

Господа, данный баг уже никого не интересует?
Вот пример, когда без apt-file не обойтись (если не ставить лишние пакеты):
$ pdflatex referat.tex 
This is pdfTeXk, Version 3.1415926-1.40.9 (Web2C 7.5.7)
<skip>
! LaTeX Error: File `extreport.cls' not found.

(В ответ на комментарий №9)
> Господа, данный баг уже никого не интересует?
> Вот пример, когда без apt-file не обойтись (если не ставить лишние пакеты):
> $ pdflatex referat.tex 
> This is pdfTeXk, Version 3.1415926-1.40.9 (Web2C 7.5.7)
> <skip>
> ! LaTeX Error: File `extreport.cls' not found.

Обойтись можно так: 
apt-get install 'texmf(latex/extreport)'

Пока_проблема_не_решена,_можно_"contents_index"_пожать?

В связи с задачей реализации поиска по файлу среди неустановленных пакетов для проекта http://wiki.etersoft.ru/Epm хочу спросить, может быть всё же есть какое-то решение?
Или надо писать apt-file, который будет искать в contents_index, который кто-то (apt-get update?) будет скачивать на машину?

Добавлю обсуждение:
http://comments.gmane.org/gmane.linux.altlinux.community/93114
и попытка реализации сжатого content_index от Алексея Турбина:
http://git.altlinux.org/people/at/packages/path-trie.git

Приходила мысль сделать индексированный поиск при помощи ftp.linux.kiev.ua
(...но никого не застав, ушла).

В epm реализован epm -sf <файл>, который на ALT Linux ищет указанный файл, пользуясь локальной копией base/contents_index

$ epm -sf motion
Search in /var/ftp/pub/ALTLinux/Sisyphus/i586/base/contents_index and /var/ftp/pub/ALTLinux/Sisyphus/noarch/base/contents_index for motion...
motion: /etc/motion/motion.conf
libemotion-devel: /usr/bin/emotion_test
motion: /usr/bin/motion
qmotion: /usr/bin/qmotion
trilinos10-headers: /usr/include/Teuchos_PromotionTraits.hpp

В Сизиф отправлен пакет eepm-2.0.4-alt1, в котором реализована поддержка epm sf для удалённых репозиториев.
Прошу проверять.

(В ответ на комментарий №14)
> Приходила мысль сделать индексированный поиск при помощи ftp.linux.kiev.ua
> (...но никого не застав, ушла).
В принципе, самое хорошее место это https://packages.altlinux.org
но с ним быстро не получается:
https://bugzilla.altlinux.org/show_bug.cgi?id=29496

Индексированный поиск делается просто: помещаем в redis и пишем обёртку, чтобы обращаться через http. Нет ли чего похожего?

resolved в сomment#16.
eepm решает данную задачу.

Это всё-таки немного не то.

(In reply to comment #19)
> Это всё-таки немного не то.
Установить пакет eepm
выдать команду
URL=http://ftp.yandex.ru/altlinux/Sisyphus/ epmsf <file name>

Какой объём трафика при этом будет скачан ?

Он будет скочивать contents_index, который занимает 129M+300M для x86_64+noarch. Причем если бы он хотя бы скочивал с помощью "rsync -z", то этот "rsync -z" ужал бы на ходу объем скочивания в несколько раз.  Но кажется этот epm rsync'ом скочивать не умеет. И кстати не понятно, чем epm отличается от eepm. Памятуя заповедь Пушкина - "на слово длинношеее в конце пришлось три е" - предлагаю лучше называть эту штуку eeepm.

Есть идея сделать отдельную псевдокомпоненту репозитория, которая вместо classic будет называться classic+bloat.  Тогда если переключить apt с classic на classic+bloat, то в файлах pkglist.classic+bloat будет доступен полный (неурезанный) список файлов в пакетах.  То есть будет работать apt-get install /usr/foo, где /usr/foo - произвольный путь, запакованный в каком-либо пакете; а команда 

$ pkglist-query '[%{NAME}\t%{FILENAMES}\n]' /var/lib/apt/lists/*pkglist.*

будет выводить полный список файлов в пакетах (сейчас там только урезанный).

Сейчас pkglist.classic.xz занимает 18M+5M для x86_64+noarch.
pkglist.classic+bloat.zst (сжатый с помощью zstd -7) будет занимать 27M+17M.
А если бы сжимать с помощью xz, то было бы 23M+13M.

(В ответ на комментарий №22)
> Он будет скочивать contents_index, который занимает 129M+300M для
Не очень ясно, зачем было класть на сервер незапакованный индекс.

> x86_64+noarch. Причем если бы он хотя бы скочивал с помощью "rsync -z", то этот
> "rsync -z" ужал бы на ходу объем скочивания в несколько раз.  Но кажется этот
Хорошая идея, если сервер не жалко.

> Есть идея сделать отдельную псевдокомпоненту репозитория, которая вместо
> classic будет называться classic+bloat.  Тогда если переключить apt с classic
> на classic+bloat, то в файлах pkglist.classic+bloat будет доступен полный
> (неурезанный) список файлов в пакетах.  То есть будет работать apt-get install
> /usr/foo, где /usr/foo - произвольный путь, запакованный в каком-либо пакете; а
> команда 
> 
> $ pkglist-query '[%{NAME}\t%{FILENAMES}\n]' /var/lib/apt/lists/*pkglist.*
> 
> будет выводить полный список файлов в пакетах (сейчас там только урезанный).

Вопрос такой. Обсуждение после Comment #16 касается уже eepm ? Может, это всё в отдельный баг на eepm перенести ?

(In reply to comment #22)

> И кстати не понятно, чем epm отличается от eepm.

# rpm -qi eepm | grep Summary
Summary     : Etersoft EPM package manager

Одно - пакет, другое - сама утилита.

(In reply to comment #24)

> > Он будет скочивать contents_index, который занимает 129M+300M для

> Не очень ясно, зачем было класть на сервер незапакованный индекс.

Не знаю, почему, но https://bugzilla.altlinux.org/30883#c4

apt-repo test 187700

Отдельно про сжатие contents_index есть bug 30887.

(In reply to comment #27)

> apt-repo test 187700

А исходя из этого (появления apf, у которого в спеке даже Provides: apt-file), думаю, баг можно закрывать. Про сжатие, думаю, надо отдельные баги на eepm и apf, если оно надо.

(В ответ на комментарий №22)
> Есть идея сделать отдельную псевдокомпоненту репозитория, которая вместо
> classic будет называться classic+bloat.
2 glebfm: я правильно помню, что теперь сборочница порождает индексы именно
с --bloat?

PS: на всякий задокументировал вот здесь, разбирающие метаданные спрашивали:

http://www.altlinux.org/pkglist-query
http://en.altlinux.org/pkglist-query

(In reply to comment #29)
> 2 glebfm: я правильно помню, что теперь сборочница порождает индексы именно
> с --bloat?

Нет, в репозиторий попадают только не-bloat индексы.  Сборочница делает bloat индексы для внутренних целей и для тасков.

(Ответ для alexey.tourbin на комментарий #22)
> Он будет скочивать contents_index, который занимает 129M+300M для
> x86_64+noarch. Причем если бы он хотя бы скочивал с помощью "rsync -z", то
> этот "rsync -z" ужал бы на ходу объем скочивания в несколько раз.  Но
Спасибо за замечание! Переделал на скачивание через rsync -z, причём сначала пробую скачать
расположенные на отдельном сервере файлы, сжатые gzip --rsyncable.

> кажется этот epm rsync'ом скочивать не умеет. И кстати не понятно, чем epm
> отличается от eepm. Памятуя заповедь Пушкина - "на слово длинношеее в конце
> пришлось три е" - предлагаю лучше называть эту штуку eeepm.
«...вывод ясен».
 
> Есть идея сделать отдельную псевдокомпоненту репозитория, которая вместо
> classic будет называться classic+bloat.  Тогда если переключить apt с
> classic на classic+bloat, то в файлах pkglist.classic+bloat будет доступен
> полный (неурезанный) список файлов в пакетах.  То есть будет работать
> apt-get install /usr/foo, где /usr/foo - произвольный путь, запакованный в
> каком-либо пакете; а команда 
> 
> $ pkglist-query '[%{NAME}\t%{FILENAMES}\n]' /var/lib/apt/lists/*pkglist.*
> 
> будет выводить полный список файлов в пакетах (сейчас там только урезанный).
...

(Ответ для at@altlinux.org на комментарий #4)
> Сейчас имеем
> 2.4M    i586/base/pkglist.classic.bz2
> 
> Предварительная оценка: если вовсе не обрезать список файлов
> при генерации репозитария, то размер pkglist.classic.bz2 увеличится
> примерно на 5M.  Это цена вопроса.  При каждом 'apt-get update'
> придётся выкачивать на 5M больше, но зато что-то типа apt-file
> сможет работать на "чистом репозитарии" без каких-либо дополнительных
> данных.
Сейчас тот же индекс занимает
19M	pkglist.classic.xz

Может быть, если не обрезать список файлов, значимого увеличения не будет, и можно вернуться к идее не обрезать список файлов?
Другое дело, что может быть apt его распаковывает в память и это может быть критично?