Где мне провести грань между использованием apt-get и gem при настройке сервера для размещения ruby на рельсах с помощью пассажира + apache?
Это вообще имеет значение?
Считается неправильным смешивать системы управления пакетами при рассмотрении обновлений программного обеспечения и так далее.
Как это сделать?
Следует иметь в виду, что обновления будут происходить намного быстрее с использованием gem, чем с официальными репозиториями apt. Возможно, есть сторонние репозитории, которые более актуальны, я не уверен. Однако у меня сложилось впечатление, что если вам нужна новейшая версия, обновляйте ее с помощью gem.
Я не использую apt-get, поскольку запускаю NetBSD, но "pkgsrc" выполняет ту же роль, что и apt-get.
Моя местная политика очень проста. Если я могу использовать драгоценный камень, я использую драгоценный камень. Если не могу, я получаю его от pkgsrc. Некоторые вещи, для которых требуется собственный код (sqlite и некоторые другие), просто не могут быть надежно установлены как драгоценные камни из коробки.
В крупный Преимущество, которое я вижу в использовании гемов для большинства вещей, заключается в том, что у меня может быть установлено несколько версий одновременно. Например, у меня установлены 3 разные версии Rails, и приложения можно медленно переносить с одной на другую.
Я не уверен, что apt-get позволит вам это сделать, но я знаю, что pkgsrc этого не делает. Это функция, которая мне нужна и которую я использую.
Наша политика заключается в том, что мы используем драгоценные камни, когда в цепочке зависимостей нет дебетов "ниже по потоку" (обычно это код, развертываемый и управляемый клиентом), но все, что мы делаем сами, упаковано должным образом, и поэтому мы свернем все зависимые гемы в дебетовые, чтобы удовлетворить эти зависимости. Различные системы упаковки не должны быть проблемой; ваш инструмент автоматизации управления системой должен уметь изящно обрабатывать различия.
Я рисую черту на песке при обновлении быстро и стабильно - это нормально
Пример Я развертываю на Hardy, если подходит Ruby 1.8.6, в противном случае последняя выпущенная Ubuntu, если мне нужна 1.8.7
Затем я устанавливаю архив rubygems, так как вам нужна последняя версия для Rails 2.3.4, а затем устанавливаю пассажира и т. Д. С помощью драгоценных камней.
В таких ситуациях, как rmagick, где вам нужно установить imagemagick, я использую системные файлы для imagemagick, а затем устанавливаю гем rmagick
Построение дебетов из драгоценных камней можно автоматизировать. Пакеты Python, OCaml, Cabal и CPAN просты. debgem это сервис gem-to-deb с 25k пакетами, но, похоже, он не стал популярным и отстает от нескольких выпусков рельсов.
«Где мне провести грань между использованием apt-get и gem при настройке сервера для размещения ruby на рельсах с помощью пассажира + apache? Это вообще имеет значение? Считается неправильным смешивать системы управления пакетами при рассмотрении обновлений программного обеспечения и так далее.»
Обратите внимание, что APT (частью которого является apt-get) является не менеджер пакетов, это менеджер зависимостей. Это очень важно; менеджер пакетов - DPKG.
Теперь правило состоит в том, что набор каталогов должен содержать только набор пакетов, управляемых одним диспетчером пакетов, иначе произойдут очень плохие вещи (например, пакет, управляемый одним, будет частично перезаписан без предупреждения пакетом, управляемым другим). .
RubyGem - это менеджер пакетов, такой как DPKG, или как Perl CPAN или Python EasyInstall загрузчики, и их никогда не следует смешивать с другими менеджерами пакетов, включая DPKG.
«Основное преимущество, которое я вижу в использовании гемов для большинства задач, заключается в том, что у меня может быть установлено более одной версии одновременно.»
То, что DPKG не может иметь разные версии или разные платформы одного и того же установленного пакета, является очень серьезным и плохим ограничением, из-за которого Debian создает крайне уродливые и некачественные обходные пути (кодирование версии и платформы в самом имени пакета). К сожалению, те, кто решил использовать DPKG, вынуждены мириться с этим ограничением.
На случай, если это не было ясно из моего предыдущего ответа:
«Неправильно смешивать системы управления пакетами»
Смешивать их действительно неправильно в том же поддереве. если вы установите две системы управления пакетами (например, DPKG и RubyGems), предоставив им разные поддеревья, это будет нормально. Вот почему «/ usr / local» - это отдельное поддерево, а «/ opt» - еще одно отдельное поддерево. RubyGems по умолчанию использует / usr / local / lib / ruby, что мне кажется правдоподобным (и не конфликтует с DPKG, но может конфликтовать с пакетами, установленными вручную).
«у вас сразу установлено несколько версий.»
Если это необходимо, используйте RubyGems в отдельном поддереве, как упомянуто выше. DPKG, как вы уже выяснили, просто не может сделать этого по-настоящему. Здесь сравниваются RubyGems и DPKG, а не RPM, который никогда не упоминался в вашем вопросе или в моем предыдущем ответе, даже если некоторые Debianistas, кажется, имеют комплекс неполноценности в отношении RPM.
Наличие нескольких версий библиотеки или приложения - очень важная функция, особенно для тестирования и производства, и особенно для веб-приложений, поэтому я бы порекомендовал RubyGems и вообще не использовать debgems.org.
Вероятно, это один из тех вопросов, где вы увидите деление 50/50. Может быть, вам стоит более точно определить критерии, чтобы получить полезный ответ.
По моему опыту, все менеджеры пакетов на основе * nix, такие как порты, macports, rpms, dpkgs и т. Д., Имеют довольно странные взаимозависимости и часто устанавливают вещи, которые вам не нужны или не нужны для вашей задачи, или нет. установите то, что вам нужно. Я не вижу такой же закономерности с драгоценными камнями или пакетами CPAN.