Lucas Nussbaum: в Debian с Ruby все нормально

> Эта проблема затрагивает не только Debian и Ruby/Python/Perl, а все дистрибутивы и любую программу позволяющую установку дополнительных модулей (TeX, Eclipse, Firefox, например).

Да, Вы совершенно правильно отметили. Я очень узко сказал.

Проблема в «чужих» репозиториях и политике Debian про apt/dpkg как единого менеджера для всего. Или трусы или крестик, в смысле - или надо отказаться от единости и сделать в файловой иерархии веточки для других пакетных систем, или делать поддаржку apt'а для чужих систем или, на худой конец, автоматические адаптеры-конверторы в deb.

не знаю, глянул на что есть в синаптик testing :
три версии пистона в системе есть,
устанлено :
python 2.5 - 2.5.5
python 2.6 - 2.6.6
без проблем можно еще поставить python3 - 3.1.2
т.е, по самое горло примеров для подобных пакетов.

Палка о двух концах. С одной стороны — да, можно было бы сделать такую возможность хотя бы. Это может выглядеть по-разному: отдельный репозиторий, например, или в бекпортах размещать. С другой стороны, теряем целостность и стабильность. Очень много разных программ на python, например, которые есть в репозитории, зависят от разного рода библиотек. И эти зависимости пересекаются у разных программ. Это могут быть XML-парсеры или какие-то привязки к dbus (я от балды какие-то примеры привожу). А теперь представь, что будет, если ты начнешь брать все из апстрима? Посыпется все к чертям и поотваливается. Лично я в этом не заинтересован. Поэтому сопровождающие могут взять на себя задачу как-то пропатчить программы, чтобы работали, договориться совместно о версиях, которые попадают в stable. Вот какие-то у меня стоят в /usr/share/python-support, например:

blender.dirs             python-dbus/            python-gtk@
dia-common.dirs          python-debianbts/       python-gtk2/
git-buildpackage/        python-fpconst/         python-pyorbit/
hal-device-manager.dirs  python-glade2/          python-soappy/
mini-dinstall/           python-gnome2/          python-support.dirs
python-chm/              python-gnome2-desktop/
python-dateutil/         python-gobject/

Поломаем что-то и что-то другое не взлетит.

(TeX, Eclipse, Firefox, например)

Emacs тоже запросто можно добавить в список. Несмотря на то, что я в состоянии скачать свежие версии программ и поставить их, я в основном пользуюсь дистрибутивными пакетами: jabber-el, org-mode и т. д. И вполне доволен. Очень часто авторы программ в Emacs пишут их без оглядки на более старые версии. Допустим, что в репозитории Emacs 21, а у программы из апстрима написано, что проверялось на Emacs 22. Слава богу, что Emacs благодаря RMS был весьма консервативен, мне приходилось ставить программки, написанные более десяти лет назад, и работало.

Но Firefox — это все-таки несколько иное. Тут особо и нет зависимостей снаружи. Программа-то одна. Просто один add-on подходит к ней, а другой — нет. А на python, perl уже написаны целые программы и фреймворки, поэтому надо заботиться о библиотеках так же, как об обычных сишных lib*.so

> Палка о двух концах.

Гм, так, вроде бы, всегда можно указать зависимости от той или иной версии. Не хватает, правда, некоего типа зависимостей Stable-With, куда включаются стабильные версии.

Чтобы было в духе:

% sudo apt-get install --unstable python-psycopg2
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will become UNSTABLE:
python-sqlalchemy (0.5.8-1 stable with python-psycopg <= 2.0.13-2)
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Do you want to continue [y/N]?

И дальше если все работает - молодец, нет - ССЗБ. Вроде бы ничего так вариант?

Эх, мечты, мечты...

И да, собственно вот за все это я не люблю пистон.
Не так нахально как ранее (2006 ...2007 год), но тихой сапой все продолжают плодить несовместимые версии и подсаживать на них своих жертв.

>Beginning Rails 3 — Cloves Carneiro Jr., Rida Al Barazi — [2010, PDF, ENG]

Спасибо.

http://rutracker.org/forum/viewtopic.php?t=3161042

>а когда программам для одной версии дистрибутива будет нужен десяток >разных версий гемов, будет уже поздно

WHAT? ты этим обвиняешь кого именно-то?

Вообще меня веселит эта позиция, типа: «мы должны предостовлять стабильный api лет 5-7», а то что эта старая версия уже не нужна не разработчикам, ни пользователям, их не волнует.

Подумай ещё, это полезно.

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

Я тебе открою сейчас небольшой секрет: для этого существует прекрасное средство, называемое RubyGems. Так вот, в случае если одной программе требуется одна версия библиотеки, другой - более старая/новая, то возможно паралленьно установить обе версии. А придумывать велосипед с квадратными колёсами, а потом ныть, что ничего не получается, что постоянные конфликты версий, что невозиожно обновить интерпретатор до свежей версии в виду того, что какой-то разработчик, который давно уже положил толстый прибор на своё детище, не хочет его обновлять - это конечно правильный подход! Ну что ж, жрите свой кактус дальше.

Винды захотелось? Проходи, не задерживайся.

>В винде есть менеджер пакетов?

лолшто. ну в общем диагноз ясен. У настоящий линуксоидов всё должно быть сложно, иначе это какая-то винда и не тру.

Позиция Debian изложена вот тут по этому поводу.

И rubygem этот пакетирован в Debian. И его можно использовать. В тексте тут написано, что только используйте его на свой риск.

A rubygems package is provided in Debian. It is aimed at developers willing to install bleeding edge library versions, or libraries that have not yet been packaged in Debian. This package provides the gem command to be able to install/remove gems at the developer’s own discretion and risk. The gems will be installed using the normal gem installation procedure, under /var/lib/gems, as the normal Gem installation path is incompatible with the FHS.

>А придумывать велосипед с квадратными колёсами, а потом ныть, что ничего не получается, что постоянные конфликты версий, что невозиожно обновить интерпретатор до свежей версии в виду того, что какой-то разработчик, который давно уже положил толстый прибор на своё детище, не хочет его обновлять - это конечно правильный подход! Ну что ж, жрите свой кактус дальше.

Я проясню ситуацию. Есть люди, которые хотят поставить программу при помощи пакетного менеджера и чтобы она сразу заработала. Многие программы, утилиты, которые я ставлю написаны то на perl, то на python. Я их запустил и они заработали. Вот возьмем для примера uniconvertor, который на python написан в целом. Мне вообще не уперлось искать, от чего он там зависит, какие мне надо библиотеки ставить, как его собирать, решать проблемы несовместимости версий библиотек (допустим программа еще работает со старыми версиями, а у автора уже все поменялось). Короче, посоветовать человеку со стороны, чтобы поставить uniconvertor и запустить, не получится. Пока что сборка — это реальная головная боль, которую иногда решает сопровождающий за меня (и спасибо ему). Разработчик осилит установку, а пользователь — нет. Мир не ограничен веб-движками. Разумеется, в репозитории нет львиной части программ, а некоторые наверняка поломаны даже в stable. Так что ставить все-равно придется.

Кстати, запеленговал даже такое (не знаю, работает ли это или нет): http://debgem.com/

> Я тебе открою сейчас небольшой секрет: для этого существует прекрасное средство, называемое RubyGems.

RubyGems не поддерживает security update'ы

Ну какбэ для питона/джанго есть кардинальное средство от головной боли: buildout.

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

Правда, если такое юзать для каждой сраной консольной утилитки, то пролучится караул.

номер версии тут неважен. Главное, это список поддерживаемых архитектур - вот это страшно

> Вот почти красиво это сделали в Gentoo - есть средства, которые берут чужой модуль (gem, egg, cpan module) и делают из него ebuild.

Я вот знаю только про g-cpan. Разве для кукаек и блестяшек тоже есть аналогичные утилиты?