[devel] I: Ruby packages 1.7.3-alt7 (IMPORTANT)

[devel] I: Ruby packages 1.7.3-alt7 (IMPORTANT)

[Alexander Bokovoy]

Greetings! 

В ALT Linux Sisyphus отправилась новая сборка пакетов Ruby. На сей раз с
существенными изменениями в инфраструктуре, о которых ниже.

Изменения:

1. Snapshot от 2002-11-18 с рядом серьезных исправлений (см. ChangeLog
   пакета ruby)

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
   
   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

   4. Порядок поиска в обозначенных директориях таков:
     /usr/local/lib/ruby/{версия}/{архитектура}
     /usr/local/share/ruby/{,версия}
     /usr/lib/ruby/vendor_ruby/{архитектура}
     /usr/share/ruby/vendor_ruby/{,версия}
     /usr/lib/ruby/{версия}/{архитектура}
     /usr/share/ruby/{,версия}
   
   Теперь любые собираемые локально модули Ruby автоматически попадают в
   /usr/local, если они используют при сборке подсистему mkmf (100%
   модулей с RAA). Автоматически появляется новая feature: независящая от
   изменений пакетов в дистрибутиве локальная установка модулей с помощью 
   rpkg: модули не затрагивают системное дерево каталогов Ruby.

3. Для сборки модулей Ruby в RPM-пакеты теперь требуется установка пакета
   libruby-devel размером 32117 байт, в котором присутствуют специальные
   макросы RPM в /etc/rpm/macros.d/ruby, автоматически учитывающие
   возможность установки пакетов в дистрибутиво-зависимые каталоги
   (/usr/{lib,share}/ruby/vendor_ruby). Сделано это следующим образом:

   - изменен rbconfig.rb так, что он подменяет sitelibdir/sitearchdir на
     vendorlibdir/vendorarchdir соответственно при определении константы
     VENDOR_SPECIFIC в true _до_ require 'mkmf'/'rbconfig'

   - добавлен /usr/share/ruby/vendor_ruby/{версия}/vendor-specific.rb,
     содержащий установку этой константы в true

   Теперь, для того, чтобы модуль установился в дистрибутивно-зависимые
   каталоги достаточно запустить его конфигурацию с предзагруженным
   vendor-specific.rb:

   ruby -rvendor-specific extconf.rb
   
   	или
	
   ruby -rvendor-specific setup.rb setup/install (для setup.rb от Minero Aoki)

   Это автоматически делается макросами из /etc/rpm/macros.d/ruby

   Если Ваш код использует значения Config::CONFIG["sitearchdir"] или
   Config::CONFIG["sitelibdir"] для определения положения своих
   специфических данных (как сделано в пакете ri) и Вы желаете собрать
   Ваше приложение в RPM-пакет, то имеет смысл где-то в головной программе
   до require 'rbconfig' сделать require 'vendor-specific'.

   Также следует при сборке в RPM обратить внимание на пакет
   ruby-stdlibs-core, который содержит в себе каталоги в
   /usr/{lib,share}/ruby. Типичный модуль, не использующий функционал из
   стандартного набора библиотек Ruby, находящихся в пакете ruby-stdlibs,
   должен при установке требовать только ruby-stdlibs-core (и, возможно,
   libruby, если это модуль на C/C++, но эта зависимость вытянется
   автоматически).

   В частности, зависимость на ruby-stdlibs-core должна выглядеть так:
   
   Requires: ruby-stdlibs-core >= 1.7.3-alt7

   и для сборки:

   BuildRequires: libruby-devel >= 1.7.3-alt7

   для того, чтобы все этапы (сборка и установка) были согласованы между
   собой.

4. Произведен переход от ruby-gnome для версии 1.x GNOME к ruby-gnome2 для
   GNOME2. Пакеты работоспособны, насколько работоспособны эти модули в
   CVS проекта Ruby-Gnome2 и, по крайней мере, могут полностью заменить
   Ruby-Gnome (который из ALT Linux Sisyphus можно теперь полностью
   убрать).

5. Все зависящие от Ruby пакеты в ALT Linux Sisyphus пересобраны с учетом
   вышеописанных изменений, так что большая просьба ответственным за них
   мейнтейнерам обратить внимание на новые версии и синхронизироваться с
   ними. Существование старых пакетов в новой схеме невозможно, поэтому и
   потребовалась такая "глобальная" пересборка. Также, прошу обязательно 
   указывать в собираемых Вами пакетах правильные BuildRequires и 
   не допускать их отсутствия.

   
-- 
/ Alexander Bokovoy
---
It's not whether you win or lose, it's how you place the blame.

[devel] Re: I: Ruby packages 1.7.3-alt7 (IMPORTANT) -- perl FHS

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3351 bytes --]

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.

>    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.


>    4. Порядок поиска в обозначенных директориях таков:
>      /usr/local/lib/ruby/{версия}/{архитектура}
>      /usr/local/share/ruby/{,версия}
>      /usr/lib/ruby/vendor_ruby/{архитектура}
>      /usr/share/ruby/vendor_ruby/{,версия}
>      /usr/lib/ruby/{версия}/{архитектура}
>      /usr/share/ruby/{,версия}
>    
>    Теперь любые собираемые локально модули Ruby автоматически попадают в
>    /usr/local, если они используют при сборке подсистему mkmf (100%
>    модулей с RAA). Автоматически появляется новая feature: независящая от
>    изменений пакетов в дистрибутиве локальная установка модулей с помощью 
>    rpkg: модули не затрагивают системное дерево каталогов Ruby.

-- 
WBR, Alexey Tourbin	"He is a sane man who can have tragedy 
BIOZAK Ltd., Russia	 in his heart and comedy in his head."
					--G.K.Chesterton

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: I: Ruby packages 1.7.3-alt7 (IMPORTANT) -- perl FHS

[Alexander Bokovoy]

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