[devel] Re: I: Ruby packages 1.7.3-alt7 (IMPORTANT) -- perl FHS
Alexander Bokovoy
=?iso-8859-1?q?a=2Ebokovoy_=CE=C1_sam-solutions=2Enet?=
Вт Дек 17 17:41:53 MSK 2002
On Tue, Dec 17, 2002 at 05:17:04PM +0300, Alexey Tourbin wrote:
> On Wed, Nov 20, 2002 at 05:59:35PM +0200, Alexander Bokovoy wrote:
> > 2. Структурные изменения путей поиска модулей теперь позволяют этой сборке
> > Ruby считаться полностью соответствующей File Hierarchy Standard. Дело
> > в том, что в обычном Ruby предполагается следующая структура каталогов
> > для модулей:
> >
> > /usr/lib/ruby/{версия}/ -- зависящие от версии модули на Ruby
> > /usr/lib/ruby/{версия}/{архитектура} -- бинарные модули для этой версии
> > /usr/lib/ruby/site_ruby/{,версия} -- локальные модули (общие для
> > всех версий и зависящие от конкретной версии)
> > /usr/lib/ruby/site_ruby/{версия}/{архитектура} -- бинарные локальные
> > модули для этой версии
> >
> > Такая схема нарушает FHS в двух вещах:
> >
> > 1. Все, независящее от архитектуры, должно быть расположено в
> > /usr/share
>
> Хочу отметить следующее: по части перла, например, "всё, независящее от
> архитектуры" может трактоваться по-разному. Архитектурно-зависимые
> перловые библиотеки состоят из нескольких частей:
>
> 1) plaintext *.pm файл, который вызывает DynaLoader;
> 1a) в этом файле находится документация в формате pod;
> 2) *.so библиотека, которую загружает DynaLoader.
>
> При таком раскладе первый файл является полностью архитектурно
> независимым, его можно с успехом шарить по сети и т.п. Однако принято,
> чтобы оба они лежали в каталоге типа i386-linux.
В Ruby противоречия не возникает -- текстовые модули, которые грузят .so,
в своих require не пишут расширений динамических библиотек, поэтому они
действительно архитектурно-независимы. Те же, которые пишут, с полным
правом могут быть помещены в архитектурно-зависимые каталоги, если для них
так необходимо присутствие расширения .so/.dll (в 99% -- не нужно).
>
> > 2. Специфические для конкретной машины компоненты должны находится в
> > /usr/local.
> >
> > Кроме того, эта схема не позволяет четко разделить локальные добавления
> > от поставляемых тем или иным производителем дистрибутива решений. В
> > результате получается мешанина файлов, осложняющая обновление пакетов.
> >
> > Новая сборка Ruby (1.7.3-alt7) исправляет эти недостатки следующим
> > образом:
> >
> > 1. Все архитектурно-независимые компоненты Ruby размещаются теперь в
> > /usr/share/ruby, все архитектурно-зависимые -- в /usr/lib/ruby
> >
> > 2. Все локальные добавления будут производится в
> > /usr/local/{lib,share}/ruby
> >
> > 3. Все поставляемые в рамках дистрибутива модули будут размещаться в
> > специфичных для производителя дистрибутива поддеревьях
> > /usr/{lib,share}/ruby/vendor_ruby/, по аналогии с новым Perl 5.8
>
> Противоречит ли FHS использование поддеревьев типа vendor_ruby?
>
> 4.7.1
>
> Applications may use a single subdirectory under /usr/lib. If an
> application uses a subdirectory, all architecture-dependent data
> exclusively used by the application must be placed within that
> subdirectory.
Нет, не противоречит. Речь идет о single subdirectory в /usr/lib. Такой
каталог там есть -- /usr/lib/ruby. А вся структура внутри него уже не
касается FHS -- в нем структурирование специфичных для приложения
каталогов не оговорено, просто требуется, чтобы на верхнем уровне
(/usr/lib) он был одним.
--
/ Alexander Bokovoy
---
To generalize is to be an idiot.
-- William Blake
Подробная информация о списке рассылки Devel