LINUX.ORG.RU

[RPM][RHEL][deployment] perl+модули версии, отличной от системной

 , ,


0

1

Собственно, следующая задача: есть система RHEL 5.5 или аналогичный CentOS. Системная версия perl (представленная пакетом «perl») на этих системах - 5.8.8. Есть некая система, которой нужен perl 5.10.0 и некоторое количество модулей под него (mod_perl и всякие мелочи).

Посмотрите, пожалуйста, верный ли выбран подход, - может быть я что-то «недогуглил»?

Собственно, проапгрейдить системный perl нельзя, т.к. у него стоит «Provides: perl(:MODULE_COMPAT_5.8.8)», а у модулей, зависящих от него (не у всех, но..) - «Requires: perl(:MODULE_COMPAT_5.8.8.)». У perl 5.10.0, соответственно, стоит «Provides: perl(:MODULE_COMPAT_5.10.0)». Если проапгрейдить - все сломается (практически все, зависящие от системного perl, пакеты ставиться не будут).

Насколько я понимаю, единственный выход - взять за основу RPM perl-5.10.0 откуда-нибудь из Федоры и сделать так, чтобы он ставился «отдельно» от всего остального. Беру RPM и перепиливаю spec-файл следующим образом:

  • переименовываю пакет perl в, допустим, perl510. Тогда все остальные пакеты, собираемые из него, будут иметь имя типа perl510-libs, perl510-core и т.п. В том числе и модули, а не только мета-пакеты.
  • соответствующим образом меняю все Provides / Requires (в том числе и определяемые автоматически) так, чтобы пакет perl510 «предоставлял» perl510, а не «perl» и т.п.
  • Все файлы, - библиотеки, бинарники, маны, ставятся под отдельный, отличный от системного (/usr), префикс, допустим /opt.

Аналогичным образом «обрабатываются» необходимые модули - имя меняется с perl-Foo-Bar на perl510-Foo-Bar, Requires / Provides тоже подменяются, чтобы не зависеть от «perl».

Этот процесс, естетственно, можно (попытаться) автоматизировать. Однако, остается нерешенным такой вопрос - что делать с «Provides» типа «libperl.so»? Оставлять, как есть?

Хотелось бы знать - «верной дорогой» ли я иду? Perl и пару модулей (в том числе и mod_perl) я пересобрал и, кажется, все работает и не конфликтует, - устанавливается / удаляется через yum.

Может быть есть какой-нибудь более «бескровный» способ? К сожалению, варианты, типа «использовать другой дистрибутив» (ах, если бы!) или «плюнуть на RPM», не подходят. Надо, чтобы все ставилось «честно».

P.S. Тысяча извинений, если ошибся с разделом.


Собери некоторую систему в один пакет, ставящийся в /opt или /usr/local. Вместе с перлом и т.п.

mv ★★★★★
()
Ответ на: комментарий от mv

Хм, да, возможно это будет менее затратно, чем перепиливать каждый пакет по-отдельности. К тому же, я видел системы, собранные именно так, правда там не perl был, а python, но смысл тот же.

shylent
() автор топика
Ответ на: комментарий от shylent

Хм, да, возможно это будет менее затратно, чем перепиливать каждый пакет по-отдельности. К тому же, я видел системы, собранные именно так, правда там не perl был, а python, но смысл тот же.

Так много кто делает. Шапку ломать сложно, чтобы всё потом работало.

mv ★★★★★
()
Ответ на: комментарий от shylent

>К тому же, я видел системы, собранные именно так, правда там не perl был, а python, но смысл тот же.

С питоном есть virtualenv, который в куче случаев подходит.

anonymous
()
Ответ на: комментарий от arsi

Эх, да. Моя бы воля, как говорится, я бы так, возможно, и сделал.

P.S. Может быть, вы уже знаете, но есть утилита cpanspec, позволяющая из CPAN-модулей генерировать некие «полуфабрикаты» spec-файлов. Их, конечно, надо вручную проверять, но это уже неплохо.

shylent
() автор топика

Может быть есть какой-нибудь более «бескровный» способ?

для так необходимых других модулей - несложно сделать так чтобы пакеты брались из локальной папки lib вашего проекта, посмотрите например структуру bugzilla

anonymous2 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.