[devel] ruby, ruby, ruby...

[Alexey I. Froloff]

(Извините за несколько сумбурное изложение - два часа ночи среды
;-)

Некоторое довольно продолжительное время мы с kas'ом общались в
жабере на тему ruby, rpm и Сизифа.  Ситуация складывается
примерно следующая:

Кирилл хочет (поправь меня если ошибаюсь) собрать ruby1.8,
ruby1.9 и возможно ruby1.6/1.7 в Сизиф с возможностью
одновременной установки разных версий.  Проблема с зависимостями.

Пакет с модулем называется ruby1.x-module-NAME, предоставляет
зависимости ruby(NAME) и ruby1.x(NAME).

Некая Софтина хочет модули, допустим foo и bar. Эти модули есть
для 1.8 (ruby1.8-module-foo, ruby1.8-module-bar) и 1.9
(ruby1.9-module-foo, ruby1.9-module-bar).  От версии ruby не
зависит, в зависимостях стоят ruby(foo) и ruby(bar), без версий.
Таким образом получается, что зависимости (с точки зрения
rpm/apt) могут быть удовлетворены устанвкой:

1. ruby1.8-module-foo и ruby1.8-module-bar
2. ruby1.8-module-foo и ruby1.9-module-bar
3. ruby1.9-module-foo и ruby1.8-module-bar
4. ruby1.9-module-foo и ruby1.9-module-bar

Из них рабочих вариантов - только 1. и 4., при условии что
используется /usr/bin/ruby нужной версии.

Таким образом этот вариант автоматически отпадает.


Если пакет с модулем предоставляет только версионную зависимость,
нужна версионная же зависимость на /usr/bin/ruby1.x с заменой
шебанга.  Работать будет только одна версия ruby и при переезде
на новую версию ruby нужно пересобирать ВСЁ что от ruby зависит,
либо всё что от ruby зависит и не является модулем тоже придётся
дублировать для всех поддерживаемых веток.

Это всё вариации на тему Питона и его Задницы (для всех) и тоже
по всей видимости отпадает.


Я предлагаю третий вариант (раз уж так хочется держать несколько
версий ruby если не в системе, то в репозитории).

Все модули автоматически зависят от libruby1.x (либо через
SONAME, либо через каталог %ruby_sitelibdir).  libruby разных
веток между собой конфликтуют.  Таким образом нельзя одновременно
установить в систему ruby1.8-module-foo и ruby1.9-module-foo, но
можно полностью заменить ruby1.8 на ruby1.9 при наличии
параллельных сборок всех модулей.  Ну а модули собираются
автоматически из чего-то типа kernel cvs под все поддерживаемые в
репозитории ветки ruby.

Остаётся открытым вопрос, что же делать с теми, кто не является
ни модулем, ни скриптом, но завязан на libruby.so.X.Y?  Сейчас
это vim, weechat и eruby (не знаю насколько последний в этом
списке уместен).  Пока этот список маленький, но никто не знает
что будет дальше.

Как один из вариантов, одна ветка об'является "основной", -devel
пакет из этой _и только из этой_ ветки алиасится на ruby-devel, с
которым собираются все кто этого хочет.

Или даже так - "остновная" ветка ruby не имеет версии в имени
пакета.  При смене "основной" ветки, старая и новая
пересобираются одновременно примерно с такими строчками с spec'е
(1.8 -> 1.9):

Name: ruby1.8
Obsoletes: ruby < %version-%release

Name: ruby
Obsoletes: ruby1.9 < %version-%release

Только боюсь apt скорее предложит снести всё что хочет старый
libruby.so.X.Y, чем заменить ruby на ruby1.8...


У кого-ньдь есть мысли по этому поводу?

-- 
Regards,
Sir Raorn.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: Digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20051110/67033d3c/attachment-0001.bin>