Говорят, есть такая штука, как apt-file. Ввиду отсутствия такой в ALT, предлагаю рядом с репозитариями класть список файлов, по аналогии с srclist. Скажем, результат "rpm -qpli *.rpm". Думаю, достаточно обновлять раз в неделю, если оно долго выполняться будет.
Уже есть. Пример: ftp://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/i586/base/contents_index правда, файл не запакован, 144 МБ.
Остаётся исправить регулярные выражения в apt-file для наших content_index. А самих их тянуть и обновлять по rsync.
(In reply to comment #1) > base/contents_index И как я его не заметил... Глаз не выцепил выше каталогов. :-) Но запаковать бы не помешало. Или, если он нужен там незапакованный, рядом бы положить запакованный.
(В ответ на комментарий №3) > (In reply to comment #1) > > > base/contents_index > > И как я его не заметил... Глаз не выцепил выше каталогов. :-) > Но запаковать бы не помешало. Или, если он нужен там незапакованный, рядом бы > положить запакованный. Забудь. glebfm@ и ldv@ не будут делать, я это сегодня уточнил.
(In reply to comment #4) > > Или, если он нужен там незапакованный, рядом бы положить > > запакованный. > Забудь. glebfm@ и ldv@ не будут делать, я это сегодня уточнил. А в чём проблема ? Именно делать не хочется, или проблема в дополнительной нагрузке на сервер при упаковке ? Скрипт в крон могу я сделать, но правильнее упаковку не по крону делать, а в момент изменения content_index запускать.
(В ответ на комментарий №5) > (In reply to comment #4) > > > > Или, если он нужен там незапакованный, рядом бы положить > > > запакованный. > > > Забудь. glebfm@ и ldv@ не будут делать, я это сегодня уточнил. > > А в чём проблема ? Именно делать не хочется, или проблема в > дополнительной нагрузке на сервер при упаковке ? Скрипт в крон могу я сделать, > но правильнее упаковку не по крону делать, а в момент изменения content_index > запускать. У них и спрашивай в отдельном баге на git.altlinux.org. Это их епархия.
(In reply to comment #6) > У них и спрашивай в отдельном баге на git.altlinux.org. Это их епархия. Спросил: http://bugzilla.altlinux.org/30887
Похоже, что это дубль bug 14449, только он там на apt висит, а не в качестве нового пакета предлагается. И про пожатый content_index там же упоминалось: http://bugzilla.altlinux.org/14449#c11
(В ответ на комментарий №6) > (В ответ на комментарий №5) > > (In reply to comment #4) > > > > > > Или, если он нужен там незапакованный, рядом бы положить > > > > запакованный. > > > > > Забудь. glebfm@ и ldv@ не будут делать, я это сегодня уточнил. > > > > А в чём проблема ? Именно делать не хочется, или проблема в > > дополнительной нагрузке на сервер при упаковке ? Скрипт в крон могу я сделать, > > но правильнее упаковку не по крону делать, а в момент изменения content_index > > запускать. > У них и спрашивай в отдельном баге на git.altlinux.org. Это их епархия. Раз делать не хотят, тогда имеет смысл частично снять остроту проблемы и реализовать поиск по пути файла на самом p.a.o (для этого всё есть, точнее, файл, содержащий необходимые данные имеется).
Написал по мотивам обсуждения на форуме http://forum.altlinux.org/index.php/topic,34714.msg255564.html#msg255564
Ввиду https://bugzilla.altlinux.org/show_bug.cgi?id=14449#c16 (появления данного функционала в eepm 2.0.4) думаю, можно этот баг закрывать, как FIXED. Утилита появилась, просто с другим названием. Искать можно так: epmsf <строка> То есть, ищется именно строка, можно так: epmsf b64/libgssrpc.so.4 Файлы качаются в /tmp/eepm/ : /tmp/eepm/ALTLinux/p8/branch/x86_64/contents_index* /tmp/eepm/ALTLinux/p8/branch/noarch/contents_index* Если файлы присутствуют, скачивание не происходит. Для обновления индексы надо удалить. Объём индексов большой, на текущий момент для p8 это x86_64/contents_index 136,78M noarch/contents_index 294,39M
Появилось ещё одно приложение: https://packages.altlinux.org/en/Sisyphus/srpms/apf Description : apf is a command line tool to search for a package containing given file or to list the contents of a package available from repository
