14449 2008-02-15 16:05:46 +0300 Поиск пакета по файлу в пакете, который есть в дистрибутиве, но не установлен. 2021-03-03 03:57:14 +0300 1 1 4 Development Sisyphus apt unstable all Linux CLOSED FIXED P2 normal --- 1 nbr placeholder alexey.tourbin asy bikr boyarsh evg glebfm gremlin icesik imz kirill kopilo4ka ktirf lav ldv mike placeholder rider vt vvk qa-sisyphus oldest_to_newest 63270 0 nbr 2008-02-15 16:05:46 +0300 Задача: Поиск пакета по файлу в пакете, который есть в дистрибутиве, но не установлен. Например, известно, что потенциально есть такая библиотека - libartsmidi.so, но пакет, содержащий её не установлен. Как найти название пакета, в котором содержится этот файл - задача сейчас непростая. В старом Mandrakе делалось запросом urpmf, в Ubuntu - частично можно просто попробовать запустить программу, и что-то (какой-то handler) скажет, в каком пакете лежит такая программа. Но для библиотек и прочих файлов это не работает. Хорошо бы иметь команду, которая бы проводила такой поиск. 63271 1 dottedmag 2008-02-15 16:07:06 +0300 JFYI: Аналогичный инструмент зовётся apt-file в Debian. 63273 2 rider 2008-02-15 16:13:31 +0300 C библиотеками проблем нет - apt-get install libartsmidi.so.1 решает этот вопрос. С остальными файлами согласен, я для этой процедуры пользуюсь grep по content_index, что не совсем корректно для пользователя. 64212 3 at 2008-02-20 17:15:48 +0300 Список файлов частично сохраняется а частично обрезается при генерации репозитария. Сохраняются следующие пути: */bin/* */sbin/* */etc/* и файлы *.so *.so.* (сохраняются ещё некоторые пути при обнаружении необходимости). Для сохранённых путей работает 'apt-get install путь'. В частности, заведомо работает 'apt-get install /usr/bin/что-угодно'. 64213 4 at 2008-02-20 17:35:11 +0300 Сейчас имеем 2.4M i586/base/pkglist.classic.bz2 Предварительная оценка: если вовсе не обрезать список файлов при генерации репозитария, то размер pkglist.classic.bz2 увеличится примерно на 5M. Это цена вопроса. При каждом 'apt-get update' придётся выкачивать на 5M больше, но зато что-то типа apt-file сможет работать на "чистом репозитарии" без каких-либо дополнительных данных. 64214 5 dottedmag 2008-02-20 17:37:54 +0300 Чтобы сократить размер выкачиваемого можно у дебиановского apt'а стянуть и адаптировать поддержку pdiff'ов. 69455 6 mutabor 2008-05-07 15:07:12 +0400 [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*, поэтому можно бОльшую часть задачи решить малой кровью. 72678 7 vvk 2008-06-18 16:13:01 +0400 Можно сделать apt-file, тягающий rsync-ом contents_index. При использовании опции -z на ALTLinux/Sisyphus/i586/base/contents_index уходит всего 5 Мб трафика. После обновления contents_index в дело идёт grep. 72693 8 wrar 2008-06-18 22:31:15 +0400 (In reply to comment #7) > Можно сделать apt-file, тягающий rsync-ом contents_index. При использовании опции -z на > ALTLinux/Sisyphus/i586/base/contents_index уходит всего 5 Мб трафика. Если он при обновлении будет совсем мало качать (а рсинкается он действительно быстро, когда я синкаю сизиф) - совсем здорово. > После обновления contents_index в дело идёт grep. А нам же надо только "в каком пакете есть файл, подходящий под такой шаблон"? Тогда всё клёво. 104895 9 bikr 2009-12-27 20:36:55 +0300 Господа, данный баг уже никого не интересует? Вот пример, когда без 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. 104965 10 kirill 2009-12-28 23:44:33 +0300 (В ответ на комментарий №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)' 104968 11 kopilo4ka 2009-12-29 03:52:40 +0300 Пока_проблема_не_решена,_можно_"contents_index"_пожать? 132612 12 lav 2012-08-06 20:08:13 +0400 В связи с задачей реализации поиска по файлу среди неустановленных пакетов для проекта http://wiki.etersoft.ru/Epm хочу спросить, может быть всё же есть какое-то решение? Или надо писать apt-file, который будет искать в contents_index, который кто-то (apt-get update?) будет скачивать на машину? 132613 13 lav 2012-08-06 20:32:08 +0400 Добавлю обсуждение: http://comments.gmane.org/gmane.linux.altlinux.community/93114 и попытка реализации сжатого content_index от Алексея Турбина: http://git.altlinux.org/people/at/packages/path-trie.git 132657 14 mike 2012-08-08 22:57:45 +0400 Приходила мысль сделать индексированный поиск при помощи ftp.linux.kiev.ua (...но никого не застав, ушла). 139185 15 lav 2013-03-31 22:53:05 +0400 В 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 162370 16 lav 2017-03-09 17:27:19 +0300 В Сизиф отправлен пакет eepm-2.0.4-alt1, в котором реализована поддержка epm sf для удалённых репозиториев. Прошу проверять. 162380 17 lav 2017-03-09 19:03:10 +0300 (В ответ на комментарий №14) > Приходила мысль сделать индексированный поиск при помощи ftp.linux.kiev.ua > (...но никого не застав, ушла). В принципе, самое хорошее место это https://packages.altlinux.org но с ним быстро не получается: https://bugzilla.altlinux.org/show_bug.cgi?id=29496 Индексированный поиск делается просто: помещаем в redis и пишем обёртку, чтобы обращаться через http. Нет ли чего похожего? 163832 18 nbr 2017-05-26 22:39:16 +0300 resolved в сomment#16. eepm решает данную задачу. 163833 19 rider 2017-05-27 10:21:17 +0300 Это всё-таки немного не то. 163839 20 nbr 2017-05-28 14:13:09 +0300 (In reply to comment #19) > Это всё-таки немного не то. Установить пакет eepm выдать команду URL=http://ftp.yandex.ru/altlinux/Sisyphus/ epmsf <file name> 163840 21 rider 2017-05-28 15:12:24 +0300 Какой объём трафика при этом будет скачан ? 163841 22 alexey.tourbin 2017-05-28 20:38:38 +0300 Он будет скочивать 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.* будет выводить полный список файлов в пакетах (сейчас там только урезанный). 163842 23 alexey.tourbin 2017-05-28 21:18:09 +0300 Сейчас pkglist.classic.xz занимает 18M+5M для x86_64+noarch. pkglist.classic+bloat.zst (сжатый с помощью zstd -7) будет занимать 27M+17M. А если бы сжимать с помощью xz, то было бы 23M+13M. 163853 24 lav 2017-05-29 19:17:47 +0300 (В ответ на комментарий №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.* > > будет выводить полный список файлов в пакетах (сейчас там только урезанный). 165307 25 asy 2017-08-17 12:55:02 +0300 Вопрос такой. Обсуждение после Comment #16 касается уже eepm ? Может, это всё в отдельный баг на eepm перенести ? (In reply to comment #22) > И кстати не понятно, чем epm отличается от eepm. # rpm -qi eepm | grep Summary Summary : Etersoft EPM package manager Одно - пакет, другое - сама утилита. 165322 26 asy 2017-08-18 09:02:52 +0300 (In reply to comment #24) > > Он будет скочивать contents_index, который занимает 129M+300M для > Не очень ясно, зачем было класть на сервер незапакованный индекс. Не знаю, почему, но https://bugzilla.altlinux.org/30883#c4 165508 27 gremlin 2017-08-31 14:02:26 +0300 apt-repo test 187700 165687 28 asy 2017-09-11 16:29:56 +0300 Отдельно про сжатие contents_index есть bug 30887. (In reply to comment #27) > apt-repo test 187700 А исходя из этого (появления apf, у которого в спеке даже Provides: apt-file), думаю, баг можно закрывать. Про сжатие, думаю, надо отдельные баги на eepm и apf, если оно надо. 183706 29 mike 2019-08-17 14:51:47 +0300 (В ответ на комментарий №22) > Есть идея сделать отдельную псевдокомпоненту репозитория, которая вместо > classic будет называться classic+bloat. 2 glebfm: я правильно помню, что теперь сборочница порождает индексы именно с --bloat? 183707 30 mike 2019-08-17 14:57:06 +0300 PS: на всякий задокументировал вот здесь, разбирающие метаданные спрашивали: http://www.altlinux.org/pkglist-query http://en.altlinux.org/pkglist-query 183720 31 glebfm 2019-08-19 13:15:14 +0300 (In reply to comment #29) > 2 glebfm: я правильно помню, что теперь сборочница порождает индексы именно > с --bloat? Нет, в репозиторий попадают только не-bloat индексы. Сборочница делает bloat индексы для внутренних целей и для тасков. 196656 32 lav 2021-03-03 03:57:14 +0300 (Ответ для 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 его распаковывает в память и это может быть критично?