Задача: Поиск пакета по файлу в пакете, который есть в дистрибутиве, но не установлен. Например, известно, что потенциально есть такая библиотека - libartsmidi.so, но пакет, содержащий её не установлен. Как найти название пакета, в котором содержится этот файл - задача сейчас непростая. В старом Mandrakе делалось запросом urpmf, в Ubuntu - частично можно просто попробовать запустить программу, и что-то (какой-то handler) скажет, в каком пакете лежит такая программа. Но для библиотек и прочих файлов это не работает. Хорошо бы иметь команду, которая бы проводила такой поиск.
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 его распаковывает в память и это может быть критично?
