[devel] libexec and x86_64: arch

[Andrei Bulava]

Dmitry V. Levin wrote:

> Пакетов i586.rpm, содержащих только не библиотеки в каталоге /usr/lib, у
> нас сейчас 2270 штук.  Если исключить пакеты, содержащие файлы меню (а они
> почему-то находятся в /usr/lib/menu), то останется всего 1513 пакета,
> хранящих в /usr/lib/ разные скрипты и данные, не являющиеся библиотеками.
> Можно ещё найти крупные партии пакетов, хранящих нечто в /usr/lib,
> например, /usr/lib/perl5.

Ага, что /usr/lib/perl5 даже удостоился отдельного упоминания в FHS
(сноска [23] в FHS-2.3).

> Пакетов, содержащих в недрах /usr/lib файлы типа "ELF 32-bit LSB executable"
> среди *.i586.rpm не менее 236 штук.

Читаем внимательно - выиграем обязательно:

"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. [23]"

Поправьте меня, если я ошибаюсь, но разве layout
/usr/lib/foo/{etc,bin,lib,sbin,share,var} из-за этой размытой
формулировки и, особенно, упоминания /usr/lib/perl5 с его (дикой) смесью
architecture-dependent и architecture-independent data (с запоздалым
упоминанием i386-linux внутри) не может считаться законным в upstream?

Практика показывает, что ещё как может :-(

То, что строчкой выше написано

"/usr/lib includes object files, libraries, and internal binaries that
are not intended to be executed directly by users or shell scripts. [22]",

а сама сноска [22] недвусмысленно говорит

"Miscellaneous architecture-independent application-specific static
files and subdirectories must be placed in /usr/share.",

upstream'у читать неинтересно, т.к. это заставит их больше думать (а
кому-то мысль об использовании autotools так и вообще ненавистна по
религиозным причинам). Раз сделано исключение для perl, то можно
продолжать пороть чушь в том же духе.

Кстати, "ELF 32-bit LSB executable" таки разрешены в /usr/lib :-\

Навскидку - LinCVS, который я когда-то так и не упаковал:

$ file /usr/share/LinCVS/lincvs.bin
/usr/share/LinCVS/lincvs.bin: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), for GNU/Linux 2.2.18, dynamically linked (uses shared
libs), stripped

Этот самый lincvs.bin и есть представитель "internal binaries that are
not intended to be executed directly by users or shell scripts", т.к.
вызывается wrapper'ом /usr/bin/lincvs.

К сожалению, дизайн LinCVS ещё тот, поэтому я не упаковал LinCVS сам
именно из-за того, что не смог оторвать "miscellaneous
architecture-independent application-specific static files and
subdirectories" в /usr/share.

IMHO, это явление - детище отображения "Program Files" на "/usr/lib" у
многих (если не у всех) приложений, разрабатываемых как
кросс-платформенные: mozilla suite, firefox, thunderbird и пр.

Так что, опять же IMHO, FHS - это сферический конь в вакууме. Начинать
вводить его в строй надо не с LinCVS и других мелочей типа mrtg ;-)
Покажите, для начала, как это будет с perl, firefox, thunderbird,
выслушайте мнение upstream по поводу вас и FHS, а уж тогда поднимайте волну.

-- 
// AB1002-UANIC