Bug 30685 - what about virtual pkg names compatible with Fedora?
Summary: what about virtual pkg names compatible with Fedora?
Status: CLOSED NOTABUG
Alias: None
Product: Sisyphus
Classification: Development
Component: rpm-build-perl (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Nobody's working on this, feel free to take it
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-28 17:51 MSK by Ivan Zakharyaschev
Modified: 2015-02-19 08:20 MSK (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Zakharyaschev 2015-01-28 17:51:27 MSK
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>
Comment 1 viy 2015-01-30 03:15:41 MSK
src.rpm можно конвертировать автоматически, и после пересборки у бинарного пакета зависимости будут в соответствии с дистрибутивом.
Comment 2 Ivan Zakharyaschev 2015-01-30 11:25:08 MSK
Я вообще не в курсе, есть ли, какое-то обоснование, чем наш формал perl-зависимостей лучше их. А если они дают одинаковые возможности, то можно было бы и не устраивать несовместимость просто так.

(В ответ на комментарий №1)
> src.rpm можно конвертировать автоматически, и после пересборки у бинарного
> пакета зависимости будут в соответствии с дистрибутивом.

Да, это хорошо. Каким инструментом конвертировать?

Но это скорее подходит разработчику, который в курсе всей этой кухни. (Ещё и напрашивается запрос на помещение такого пакета в autoimports. Но я не уверен, что nix есть в репозиториях Fedora; может быть, есть только пакеты от создателя.)

А пользователь, у которого был бы шанс просто поставить чужой .rpm от upstream, оказывается застопорен без помощи разработчиков.

(По мелочи виртуальные provides для совместимости добавлялись в пакеты, например, в cups для установки сторонних драйверов от Xerox в виде rpm.)
Comment 3 viy 2015-01-30 21:16:05 MSK
не хуже и чуть может лучше (поддержка require a.pl), и исторически сложился.
беда с двойными Provides: та, что индексы rpm не резиновые и забивать их лишним чревато тормозами.

nix я мотрел, там надо руками допилить, у меня пока руки не дойдут.
конвертер - надо установить /usr/bin/srpmconvert-fc и пакет distromap-fedora-rawhide-altlinux-sisyphus положить тарбол в SOURCES и запустить /usr/bin/srpmconvert-fc -i nix.spec
Comment 4 Ivan Zakharyaschev 2015-01-31 01:20:13 MSK
(В ответ на комментарий №3)
> не хуже и чуть может лучше (поддержка require a.pl), и исторически сложился.

То, что не хуже, я и не сомневался. (Но может, в Fedora изобрели то же самое по возможностям.)

> беда с двойными Provides: та, что индексы rpm не резиновые и забивать их лишним
> чревато тормозами.

Ну есть и радикальное решение: те, которые совпадают по смыслу с Fedora, заменить на fedorовские.
Comment 5 viy 2015-01-31 01:25:21 MSK
сломается совместимость при обновлениях :( тоже не годится.
Comment 6 Ivan Zakharyaschev 2015-02-19 08:20:23 MSK
(In reply to comment #5)
> сломается совместимость при обновлениях :( тоже не годится.

Переезд на set-versions пережили ведь.

Хотя там несколько другое соотношение частей, которые ломаются было: тогда чтобы поставить новый пакет, приходилось обновлять все зависимости. Но в принципе новый пакет с библиотекой удовлетворял старые зависимости (старых пакетов). При гипотетической замене названий perl-provides новый пакет не будет удовлетворять зависимости старых пакетов.

Да это вроде не так и страшно: т.е. нельзя будет, скажем, спокойно поставить модуль из Sisyphus в branch, но это не обещано, а важные обновления модулей для бранчей собираются по старой схеме.

(Я просто рассуждаю гипотетически, чтобы лучше понять, как это могло бы сработать, но не утверждаю, что это нужно делать.)