Now it is just impossible at all to install a package for Fedora with Perl deps into ALT. Because the virtual perl packages for perl modules have different format in ALT and Fedora. Since there might be interesting packages available for Fedora, why not consider making the names compatible? (Or are there other substantial incompatibilities in perl that would make such packages not work?) Example: the installation of nix package for Fedora is impossible -- https://bugzilla.altlinux.org/show_bug.cgi?id=30684#c3 . apt> install nix Некоторые пакеты установить невозможно. Это может означать, что Вы потребовали невозможного, либо пользуетесь нестабильным репозиторием. Часть необходимых пакетов либо ещё не создана, либо была удалена из каталога 'Входящие'. Так как для выполнения Вашего запроса достаточно одной операции, то скорее всего этот пакет просто невозможно установить. Сообщите, пожалуйста, об этом как о найденной ошибке в пакете. Эти сведения могут помочь найти выход из ситуации: Следующие пакеты имеют неудовлетворенные зависимости: nix: Требует: perl(Cwd) но пакет не может быть установлен Требует: perl(DBD::SQLite) но пакет не может быть установлен Требует: perl(DBI) но пакет не может быть установлен Требует: perl(Encode) но пакет не может быть установлен Требует: perl(English) но пакет не может быть установлен Требует: perl(Exporter) но пакет не может быть установлен Требует: perl(Fcntl) но пакет не может быть установлен Требует: perl(File::Basename) но пакет не может быть установлен Требует: perl(File::Copy) но пакет не может быть установлен Требует: perl(File::Path) но пакет не может быть установлен Требует: perl(File::Temp) но пакет не может быть установлен Требует: perl(File::stat) но пакет не может быть установлен Требует: perl(IO::Handle) но пакет не может быть установлен Требует: perl(IO::Select) но пакет не может быть установлен Требует: perl(IPC::Open2) но пакет не может быть установлен Требует: perl(List::Util) но пакет не может быть установлен Требует: perl(MIME::Base64) но пакет не может быть установлен Требует: perl(POSIX) но пакет не может быть установлен Требует: perl(WWW::Curl::Easy) но пакет не может быть установлен Требует: perl(WWW::Curl::Multi) но пакет не может быть установлен Требует: perl(utf8) но пакет не может быть установлен Требует: perl(warnings) но пакет не может быть установлен Требует: rpmlib(FileDigests) (<= 4.6.0-1) но пакет не может быть установлен E: Извините, `битые' пакеты apt> ALT's perl packages provide the virtual packages in a different format unfortunately: apt> showpkg perl-WWW-Curl Package: perl-WWW-Curl Versions: 4.15-alt3(/var/lib/apt/lists/ftp.altlinux.org_pub_distributions_ALTLinux_t7_branch_x86%5f64_base_pkglist.classic) Reverse Depends: i586-perl-WWW-Curl.32bit,perl-WWW-Curl 4.15-alt3 Dependencies: 4.15-alt3 - /usr/lib64/perl5 (0 (null)) libc.so.6(GLIBC_2.14)(64bit) (0 (null)) libc.so.6(GLIBC_2.15)(64bit) (0 (null)) libc.so.6(GLIBC_2.2.5)(64bit) (0 (null)) libcurl.so.4()(64bit) (2 set:jeubtI94OqnvVZ84Y7mkmt8URKTZ8D73d0sJohSAIQJG1rFrpgvLNJ2Nbb) libperl-5.16.so()(64bit) (2 set:oib4KrVf0I95nbfJx2X9WiH3BtSgrgsS8y9MWYtkhH9N6cMnw4m4K6KxZceXrkRZ1jcQbISDpqCguKBhrJTXwQ5W4mCMRh54Z4aFp5eUrU1lFUTFKPMJmGV8NopcBJQyiEi2UKxjaSkK1) libpthread.so.0(GLIBC_2.2.5)(64bit) (0 (null)) perl(XSLoader.pm) (0 (null)) rtld(GNU_HASH) (0 (null)) Provides: 4.15-alt3 - perl-WWW-Curl perl(WWW/Curl/Share.pm) perl(WWW/Curl/Multi.pm) perl(WWW/Curl/Form.pm) perl(WWW/Curl/Easy.pm) perl(WWW/Curl.pm) Reverse Provides: perl-WWW-Curl 4.15-alt3 apt>
src.rpm можно конвертировать автоматически, и после пересборки у бинарного пакета зависимости будут в соответствии с дистрибутивом.
Я вообще не в курсе, есть ли, какое-то обоснование, чем наш формал perl-зависимостей лучше их. А если они дают одинаковые возможности, то можно было бы и не устраивать несовместимость просто так. (В ответ на комментарий №1) > src.rpm можно конвертировать автоматически, и после пересборки у бинарного > пакета зависимости будут в соответствии с дистрибутивом. Да, это хорошо. Каким инструментом конвертировать? Но это скорее подходит разработчику, который в курсе всей этой кухни. (Ещё и напрашивается запрос на помещение такого пакета в autoimports. Но я не уверен, что nix есть в репозиториях Fedora; может быть, есть только пакеты от создателя.) А пользователь, у которого был бы шанс просто поставить чужой .rpm от upstream, оказывается застопорен без помощи разработчиков. (По мелочи виртуальные provides для совместимости добавлялись в пакеты, например, в cups для установки сторонних драйверов от Xerox в виде rpm.)
не хуже и чуть может лучше (поддержка require a.pl), и исторически сложился. беда с двойными Provides: та, что индексы rpm не резиновые и забивать их лишним чревато тормозами. nix я мотрел, там надо руками допилить, у меня пока руки не дойдут. конвертер - надо установить /usr/bin/srpmconvert-fc и пакет distromap-fedora-rawhide-altlinux-sisyphus положить тарбол в SOURCES и запустить /usr/bin/srpmconvert-fc -i nix.spec
(В ответ на комментарий №3) > не хуже и чуть может лучше (поддержка require a.pl), и исторически сложился. То, что не хуже, я и не сомневался. (Но может, в Fedora изобрели то же самое по возможностям.) > беда с двойными Provides: та, что индексы rpm не резиновые и забивать их лишним > чревато тормозами. Ну есть и радикальное решение: те, которые совпадают по смыслу с Fedora, заменить на fedorовские.
сломается совместимость при обновлениях :( тоже не годится.
(In reply to comment #5) > сломается совместимость при обновлениях :( тоже не годится. Переезд на set-versions пережили ведь. Хотя там несколько другое соотношение частей, которые ломаются было: тогда чтобы поставить новый пакет, приходилось обновлять все зависимости. Но в принципе новый пакет с библиотекой удовлетворял старые зависимости (старых пакетов). При гипотетической замене названий perl-provides новый пакет не будет удовлетворять зависимости старых пакетов. Да это вроде не так и страшно: т.е. нельзя будет, скажем, спокойно поставить модуль из Sisyphus в branch, но это не обещано, а важные обновления модулей для бранчей собираются по старой схеме. (Я просто рассуждаю гипотетически, чтобы лучше понять, как это могло бы сработать, но не утверждаю, что это нужно делать.)
