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 <[email protected]> _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
