Bug 14449 - Поиск пакета по файлу в пакете, который есть в дистрибутиве, но не установлен.
: Поиск пакета по файлу в пакете, который есть в дистрибутиве, но не установлен.
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/apt)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2008-02-15 16:05 by
Modified: 2017-09-12 10:33 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


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

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


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

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

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

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

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

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

Индексированный поиск делается просто: помещаем в redis и пишем обёртку, чтобы
обращаться через http. Нет ли чего похожего?
------- Comment #18 From 2017-05-26 22:39:16 -------
resolved в сomment#16.
eepm решает данную задачу.
------- Comment #19 From 2017-05-27 10:21:17 -------
Это всё-таки немного не то.
------- Comment #20 From 2017-05-28 14:13:09 -------
(In reply to comment #19)
> Это всё-таки немного не то.
Установить пакет eepm
выдать команду
URL=http://ftp.yandex.ru/altlinux/Sisyphus/ epmsf <file name>
------- Comment #21 From 2017-05-28 15:12:24 -------
Какой объём трафика при этом будет скачан ?
------- Comment #22 From 2017-05-28 20:38:38 -------
Он будет скочивать 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 From 2017-05-28 21:18:09 -------
Сейчас pkglist.classic.xz занимает 18M+5M для x86_64+noarch.
pkglist.classic+bloat.zst (сжатый с помощью zstd -7) будет занимать 27M+17M.
А если бы сжимать с помощью xz, то было бы 23M+13M.
------- Comment #24 From 2017-05-29 19:17:47 -------
(В ответ на комментарий №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 From 2017-08-17 12:55:02 -------
Вопрос такой. Обсуждение после Comment #16 касается уже eepm ? Может, это всё в
отдельный баг на eepm перенести ?

(In reply to comment #22)

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

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

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

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

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

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

(In reply to comment #27)

> apt-repo test 187700

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