[devel] ruby-rake и gems

Mikhail Yakshin =?iso-8859-1?q?greycat_=CE=C1_altlinux=2Eorg?=
Пн Мар 13 18:24:14 MSK 2006


Приветствую!

>>Только недавно общался с kas@, проблема в целом и общем вырисовалась
>>следующая. Обновили (ладно, сделали - так уже сделали, скажем, пусть это
>>будет NMU) ruby-rake, сделав его сборку из tarball'а, а не из gem'а.
>>
>>В итоге сейчас любой пакет, который начинает собираться или ставится из
>>gems (gem install) - падает с примерно такой ошибкой:
>>
>>$ rpmbuild -ba ruby-rails.spec
>>
>>[...]
>>
>>+ cd ruby-rails-1.0.0
>>+ gem install rails --local --install-dir
>>/home/greycat/tmp/ruby-rails-buildroot/usr/lib/ruby/gems/1.8/
>>Attempting local installation of 'rails'
>>ERROR:  Error installing gem rails[.gem]: rails requires rake >= 0.6.2
>>
>>Потому как действительно в системе не стоит gem rake. Какие будут мнения
>>на этот счет? Неконструктивный флейм на тему "почему gems - это плохо",
>>про FHS и все остальное - можно не повторять, аргументы противников gems
>>я помню.
> 
> Для меня очевидными являются два решения:
> 1. Доводить gems до вменяемого состояния. Например научить его смотреть не
> только в gems(техническими подробноcтями не владею).

Технических подробностей и нет. В ruby нет версионирования файлов,
правильно? Поэтому просто так программа не может потребовать файл
такой-то версии такой-то, как тут например (см. выше) - требуется rake
>= 0.6.2.

Единственный вариант, который я вижу - ломать gems на предмет смотрения
в базы RPM - думаю, это совсем крайний случай.

> 2. Собирать не из gems.

Всё ломать на тему отрывания gems - малореально, очень сложно и очень
bug-prone. Мы не сможем его оттестировать в достаточной мере, и каждый
апдейт будет превращаться в кошмар - все придется по сути переделывать
заново. Опять же - потом по сути лишаем юзера любой поддержки, кроме
нашей. Всё, что не пройдет через наши руки - будет невозможно установить.

У меня есть, как ни банально - предложение решить все третьим вариантом:
вернуть сборку ruby-rake из gems и не трогать ее.

> Для себя я выбрал, на сегодняшний день, я выбираю второй вариант.
> 
> P.S. А пропатчить rubygems на придмет fhs было бы классно.

Вообще - формально если - rubygems вполне соответствует FHS. Иначе бы в
Сизиф оно вообще не попадало. Архитектурно-зависимых вещей в noarch
пакеты не кладем, в share тоже их не попадает. То, что хочется сделать,
чтобы было красиво - я не против, но это требует каких-то весьма
значительных телодвижений - и, самое главное - я не вижу в них большого
смысла и выгоды. Очередной раз покажу на perl, который лежит так, как
лежит везде - и это почему-то никто не рвется переделать.

-- 
WBR, Mikhail Yakshin AKA GreyCat



Подробная информация о списке рассылки Devel