64-bitowe binarki w /usr/lib

[Tomasz Pala]

On Fri, Jun 30, 2017 at 13:50:20 +0200, Adam Osuchowski wrote:

>> No i powiedz mi, gdzie jest 'prawidłowiej'?
> 
> IMHO w /usr/lib64 ale to wyłącznie ze względu na multiliba.

multilib dotyczy .so, prywatne moduły przychodzące z binarką się nie
łapią pod ten termin. Owszem, można zainstalować binarki w różnych
architekturach... ale to koszmar.

> Na systemie
> 64-bit only osobiście mógłbym mieć wszystko w /usr/lib. Przynjamniej
> dopełnianie w shellu byłoby prostsze.

Jakie ma znaczenie, czy system jest mieszany czy czysty, gdy git-core
masz jeden pakiet?

>> W takim razie ta lokalizacja jest bez znaczenia.
> 
> Owszem, z dokładnością do multiliba, jak wyżej. I pytanie co oznacza,
> że jest bez znaczenia: że każdy może sobie wybrać co mu się podoba czy
> że wybieramy którąś z nich ale jedną, żeby było spójnie?

Albo zrobimy libexec, który do tego służy, albo należy tę kwestię po
prostu zignorować - bo ani nie powoduje realnych problemów, ani nie jest
nieprawidłowo.

>> No, rozróżnianie po 'ważności' to już przesada. Nawet wyznacznik
>> techniczny: 'system ma wstać bez dostępu do /usr', jest już mocno
>> dyskusyjny, a co dopiero jakiśtam rpm.
> 
> Chyba nie rozumiem. Sam stwierdziłeś, że na rpmie się multiliba nie robi.
> Zgoda. Ale skoro ,,ważność'' nie jest istotna, to na niczym się w takim
> razie nie powinno robić.

No właśnie. Więc /usr/libexec/rpm, /usr/libexec/mc, /usr/libexec/git.
Albo niech sobie ląduje gdzie chce, bo to jest i tak bez znaczenia.
Robienie roboty tylko dla samej roboty jest bez sensu - a ustalanie
lokalizacji tego typu plików albo będzie wprowadzało dodatkowy porządek
(libexec), albo będzie zbędną kosmetyką (lib czy lib64).

>> To nie jest jeszcze jeden potencjalny, a zupełnie inny - tam trafiają
>> prywatne moduły, a nie biblioteki współdzielone. Funkcjonalne
>> wydzielenie czegoś nie może zwiększać bałaganu...
> 
> Pisząc tu ,,współdzielone'' masz na myśli ogólnie biblioteki .so czy te,
> które są używane przez więcej niż jeden pakiet? Bo jeżeli to drugie, to

Mam na myśli binarki, które udostępniają publiczne ABI i są 'legalnie'
uruchamiane przez ZEWNĘTRZNE aplikacje (nie: inny pakiet z tego samego
drzewa). Czyli nawet nie wszystkie .so, a jedynie mniej-więcej te, do
których są dostępne devele.

> w przypadku gita czy dovecota te binarki to są właśnie dokładnie własne
> moduły i dlatego jakby był jeszcze możliwy trzeci katalog na ich
> umiejscowienie (poza lib i lib64) to bałagan byłby jeszcze większy.

To mamy chyba rozbieżne definicje 'bałaganu'. Powiedz mi - co binarki
gita robią w /usr/lib*? Czy gdyby /usr/share/doc/git-* przenieść również
do /usr/lib, czyli zlikwidować jeden katalog, to zmniejszymy bałagan?
Była kiedyś dystrybucja, która chciała pakietować każdy pakiet w swoim
katalogu, a'la windows.

> Ja bym powiedział raczej, że było dobrze i w pewnym momencie ktoś ten
> bałagan celowo wprowadził:
> 
> https://git.pld-linux.org/?p=packages/git-core.git;a=blobdiff;f=git-core.spec;h=ad97d6bf6d5d1780af42cef74059fd5e76c3cdcd;hp=ef53117014cd23cbf07dae6cf3a611874876bb6f;hb=6743dd7eda7fdf45a0e70c079ac80440814754e9;hpb=ad39aec1a27ea283c19a4c450fa18d37ab0a7d28

Ale jak wprowadził bałagan? Skoro już ustaliliśmy, że jest bez
znaczenia, czy będzie lib czy lib64, to poziom bałaganu się tym commitem
nie zmienił. A gdyby to przenieść do libexec, to by się zmniejszył - bo
od razu byś wiedział, gdzie te pliki być POWINNY.

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