[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