64-bitowe binarki w /usr/lib

[Tomasz Pala]

On Tue, Jul 04, 2017 at 05:36:23 +0200, Jakub Bogusz wrote:

> O ile pamiętam - wg FHS 3.0, jeżeli jest używane /usr/libexec, to ma być
> używane konsekwentnie.

Konsekwentnie _w obrębie danej aplikacji_. Link z początku:

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html

Applications which use /usr/libexec in this way must not also use
/usr/lib to store *internal* binaries, though they may use /usr/lib for
the other purposes documented here.

> Jak dla mnie - przy multilibie jest to trzeci, dodatkowy katalog,
> nadmiarowy.

Równie nadmiarowy jak /usr/share/{doc,info,man}. A powiem więcej,
cytując nadal FHS, podkreślenie moje:

Some previous versions of this document did not support /usr/libexec,
despite it being standard practice in a number of environments. [26] To
accomodate this restriction, it became common practice to use /usr/lib
instead. Either practice is now acceptable, but *EACH APPLICATION* must
choose one way or the other to organize itself.


Co to dla mnie oznacza - MY powinniśmy mieć poprawnie zdefiniowane
katalogi: %_libexecdir to /usr/libexec, bo nie widzę nigdzie klauzuli,
która pozwala NAM, jako dystrybucji, na łączenie czy przedefiniowywanie
katalogów.

Natomiast to _autor aplikacji_ decyduje, czy zamierza używać
%_prefix/lib, %_libdir czy też %_libexec.

Idąc taką wykładnią (strict), obecnie jesteśmy niezgodni z FHS, bo
przenosimy lokalizację z /usr/libexec wbrew woli autora _aplikacji_.

A zwracam na to (nieco przesadnie, wiem) uwagę, bo ten rozdział wyraźnie
mówi o decyzji na poziomie aplikacji, a nie systemu (host-specific); a
pamiętajmy, że FHS nie jest distribution-agnostic, bo wprost określa
takie miejsca jak /usr/local czy /opt.

> Jak jest jakaś binarka wywoływana z poziomu biblioteki, to zwykle
> i binarki przychodzą dwie wersje, więc trzeba je rozdzielić (/usr/lib
> i /usr/lib64, jak wersje biblioteki).

I to powinno być zorganizowane poprawnie w upstreamie - takie binarki
muszą używać (arch-dependent) %_libdir. Ale o tym nie ma co rozmawiać,
bo zarówno my jak i inne dystrybucje mają to ogarnięte.

> /usr/libexec nadawałoby się dla prywatnych binarek uruchamianych
> z ogólnodostępnych binarek, ale równie dobrze można skorzystać
> z istniejących już lokalizacji i nie tworzyć nowego katalogu.

Pytanie właśnie brzmi, czy na prawdę RÓWNIE dobrze. Jak dotrę do swojego
repo to poszukam, gdzie walczyłem ze zmiennym %_libdirem, bo _wydaje_ mi
się, że tam właśnie libexec byłby znacznie prostszy i adekwatny.

Ponadto, w obecnym naszym układzie nie mam pewności, że nie zaśmiecamy
czymś samego %_libdira (bez podkatalogów). Ale nawet jeżeli nie będzie
tam nic zbędnego (co tylko spowalnia linkera), to i tak:

ls -la /usr/lib64 | grep drwx | wc -l
142

na 3093, 4,5% zawartości całego katalogu.

A w sumie... już widzę biblioteki, których być w LD_LIBRARY_PATH chyba NIE powinno:

sshnodelay.so - sshfs-fuse
stderred.so - stderred
preloadable_libintl.so - gettext-tools (?)
libddr_*.so - dd_rescue


Poza tym wciąż mamy problem z multilibem, gdy jeden pakiet poza
bibliotekami publicznymi zawiera binarki (które skonfliktują przy
instalacji). Wprowadzenie libexeca pozwoliłoby na wprowadzenie
(kiedyś) dodatkowego warunku przy budowaniu pakietów, że nie pozwalamy,
aby jeden wynikowy pakiet zawierał pliki w %_libdir oraz %_bindir (bo to
jest najczęstszy konflikt, oczywiście zdarzają się również w %_datadir,
ale to by wyłapało najwięcej przypadków). Tak długo, jak nie będzie
libexeca, nie można wprowadzić żadnych restrykcji na %_libdir.

Powoli odnoszę wrażenie, że także w obszarze porządku inne dystrybucje
nas już przegoniły...

-- 
Tomasz Pala <gotar at pld-linux.org>