Bug 14449

Summary: Поиск пакета по файлу в пакете, который есть в дистрибутиве, но не установлен.
Product: Sisyphus Reporter: nbr <nbr>
Component: aptAssignee: placeholder <placeholder>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: normal    
Priority: P2 CC: alexey.tourbin, asy, bikr, boyarsh, evg, glebfm, gremlin, icesik, imz, kirill, kopilo4ka, ktirf, lav, ldv, mike, placeholder, rider, vvk
Version: unstable   
Hardware: all   
OS: Linux   

Description nbr 2008-02-15 16:05:46 MSK
Задача:
Поиск пакета по файлу в пакете, который есть в дистрибутиве, но не установлен.
 
Например, известно, что потенциально есть такая библиотека - libartsmidi.so, но
пакет, содержащий её не установлен. Как найти название пакета, в котором
содержится этот файл - задача сейчас непростая.

В старом Mandrakе делалось запросом urpmf, в Ubuntu - частично можно просто
попробовать запустить программу, и что-то (какой-то handler) скажет, в каком
пакете лежит такая программа. Но для библиотек и прочих файлов это не работает.


Хорошо бы иметь команду, которая бы проводила такой поиск.
Comment 1 Mikhail Gusarov 2008-02-15 16:07:06 MSK
JFYI: Аналогичный инструмент зовётся apt-file в Debian.
Comment 2 Anton Farygin 2008-02-15 16:13:31 MSK
C библиотеками проблем нет - apt-get install libartsmidi.so.1 решает этот вопрос.

С остальными файлами согласен, я для этой процедуры пользуюсь grep по
content_index, что не совсем корректно для пользователя.
Comment 3 at@altlinux.org 2008-02-20 17:15:48 MSK
Список файлов частично сохраняется а частично обрезается при генерации
репозитария.  Сохраняются следующие пути: */bin/* */sbin/* */etc/* и файлы *.so
*.so.* (сохраняются ещё некоторые пути при обнаружении необходимости).

Для сохранённых путей работает 'apt-get install путь'.
В частности, заведомо работает 'apt-get install /usr/bin/что-угодно'.
Comment 4 at@altlinux.org 2008-02-20 17:35:11 MSK
Сейчас имеем
2.4M    i586/base/pkglist.classic.bz2

Предварительная оценка: если вовсе не обрезать список файлов
при генерации репозитария, то размер pkglist.classic.bz2 увеличится
примерно на 5M.  Это цена вопроса.  При каждом 'apt-get update'
придётся выкачивать на 5M больше, но зато что-то типа apt-file
сможет работать на "чистом репозитарии" без каких-либо дополнительных
данных.
Comment 5 Mikhail Gusarov 2008-02-20 17:37:54 MSK
Чтобы сократить размер выкачиваемого можно у дебиановского apt'а стянуть и 
адаптировать поддержку pdiff'ов.
Comment 6 Yury Aliaev 2008-05-07 15:07:12 MSD
[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*, поэтому можно бОльшую часть задачи
решить малой кровью.
Comment 7 Vladimir V. Kamarzin 2008-06-18 16:13:01 MSD
Можно сделать apt-file, тягающий rsync-ом contents_index. При использовании опции -z на ALTLinux/Sisyphus/i586/base/contents_index уходит всего 5 Мб трафика.

После обновления contents_index в дело идёт grep.
Comment 8 Andrey Rahmatullin 2008-06-18 22:31:15 MSD
(In reply to comment #7)
> Можно сделать apt-file, тягающий rsync-ом contents_index. При использовании опции -z на
> ALTLinux/Sisyphus/i586/base/contents_index уходит всего 5 Мб трафика.
Если он при обновлении будет совсем мало качать (а рсинкается он действительно быстро, когда я синкаю сизиф) - совсем здорово.

> После обновления contents_index в дело идёт grep.
А нам же надо только "в каком пакете есть файл, подходящий под такой шаблон"? Тогда всё клёво.
Comment 9 Rinat Bikov 2009-12-27 20:36:55 MSK
Господа, данный баг уже никого не интересует?
Вот пример, когда без 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.
Comment 10 kirill 2009-12-28 23:44:33 MSK
(В ответ на комментарий №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)'
Comment 11 Vadim Gusev 2009-12-29 03:52:40 MSK
Пока_проблема_не_решена,_можно_"contents_index"_пожать?
Comment 12 Vitaly Lipatov 2012-08-06 20:08:13 MSK
В связи с задачей реализации поиска по файлу среди неустановленных пакетов для проекта http://wiki.etersoft.ru/Epm хочу спросить, может быть всё же есть какое-то решение?
Или надо писать apt-file, который будет искать в contents_index, который кто-то (apt-get update?) будет скачивать на машину?
Comment 13 Vitaly Lipatov 2012-08-06 20:32:08 MSK
Добавлю обсуждение:
http://comments.gmane.org/gmane.linux.altlinux.community/93114
и попытка реализации сжатого content_index от Алексея Турбина:
http://git.altlinux.org/people/at/packages/path-trie.git
Comment 14 Michael Shigorin 2012-08-08 22:57:45 MSK
Приходила мысль сделать индексированный поиск при помощи ftp.linux.kiev.ua
(...но никого не застав, ушла).
Comment 15 Vitaly Lipatov 2013-03-31 22:53:05 MSK
В 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
Comment 16 Vitaly Lipatov 2017-03-09 17:27:19 MSK
В Сизиф отправлен пакет eepm-2.0.4-alt1, в котором реализована поддержка epm sf для удалённых репозиториев.
Прошу проверять.
Comment 17 Vitaly Lipatov 2017-03-09 19:03:10 MSK
(В ответ на комментарий №14)
> Приходила мысль сделать индексированный поиск при помощи ftp.linux.kiev.ua
> (...но никого не застав, ушла).
В принципе, самое хорошее место это https://packages.altlinux.org
но с ним быстро не получается:
https://bugzilla.altlinux.org/show_bug.cgi?id=29496

Индексированный поиск делается просто: помещаем в redis и пишем обёртку, чтобы обращаться через http. Нет ли чего похожего?
Comment 18 nbr 2017-05-26 22:39:16 MSK
resolved в сomment#16.
eepm решает данную задачу.
Comment 19 Anton Farygin 2017-05-27 10:21:17 MSK
Это всё-таки немного не то.
Comment 20 nbr 2017-05-28 14:13:09 MSK
(In reply to comment #19)
> Это всё-таки немного не то.
Установить пакет eepm
выдать команду
URL=http://ftp.yandex.ru/altlinux/Sisyphus/ epmsf <file name>
Comment 21 Anton Farygin 2017-05-28 15:12:24 MSK
Какой объём трафика при этом будет скачан ?
Comment 22 alexey.tourbin 2017-05-28 20:38:38 MSK
Он будет скочивать 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.*

будет выводить полный список файлов в пакетах (сейчас там только урезанный).
Comment 23 alexey.tourbin 2017-05-28 21:18:09 MSK
Сейчас pkglist.classic.xz занимает 18M+5M для x86_64+noarch.
pkglist.classic+bloat.zst (сжатый с помощью zstd -7) будет занимать 27M+17M.
А если бы сжимать с помощью xz, то было бы 23M+13M.
Comment 24 Vitaly Lipatov 2017-05-29 19:17:47 MSK
(В ответ на комментарий №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 25 Sergey Y. Afonin 2017-08-17 12:55:02 MSK
Вопрос такой. Обсуждение после Comment #16 касается уже eepm ? Может, это всё в отдельный баг на eepm перенести ?

(In reply to comment #22)

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

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

Одно - пакет, другое - сама утилита.
Comment 26 Sergey Y. Afonin 2017-08-18 09:02:52 MSK
(In reply to comment #24)

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

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

Не знаю, почему, но https://bugzilla.altlinux.org/30883#c4
Comment 27 Alexey Vissarionov 2017-08-31 14:02:26 MSK
apt-repo test 187700
Comment 28 Sergey Y. Afonin 2017-09-11 16:29:56 MSK
Отдельно про сжатие contents_index есть bug 30887.

(In reply to comment #27)

> apt-repo test 187700

А исходя из этого (появления apf, у которого в спеке даже Provides: apt-file), думаю, баг можно закрывать. Про сжатие, думаю, надо отдельные баги на eepm и apf, если оно надо.
Comment 29 Michael Shigorin 2019-08-17 14:51:47 MSK
(В ответ на комментарий №22)
> Есть идея сделать отдельную псевдокомпоненту репозитория, которая вместо
> classic будет называться classic+bloat.
2 glebfm: я правильно помню, что теперь сборочница порождает индексы именно
с --bloat?
Comment 30 Michael Shigorin 2019-08-17 14:57:06 MSK
PS: на всякий задокументировал вот здесь, разбирающие метаданные спрашивали:

http://www.altlinux.org/pkglist-query
http://en.altlinux.org/pkglist-query
Comment 31 Gleb F-Malinovskiy 2019-08-19 13:15:14 MSK
(In reply to comment #29)
> 2 glebfm: я правильно помню, что теперь сборочница порождает индексы именно
> с --bloat?

Нет, в репозиторий попадают только не-bloat индексы.  Сборочница делает bloat индексы для внутренних целей и для тасков.
Comment 32 Vitaly Lipatov 2021-03-03 03:57:14 MSK
(Ответ для 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 его распаковывает в память и это может быть критично?