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 <go...@pld-linux.org> _______________________________________________ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl