Metoda

Autorem pomysłu na taki sposób zarządzania pakietami jest Matthias S. Benkmann. Teksty w tej części strony to tłumaczenie na język polski. Oryginał jest dostępny pod adresemhttp://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt

Jest to jeden z wielu sposobów na zarządzanie pakietami w dystrybucjach, w których oprogramowanie kompiluje i instaluje się z kodu źródłowego. Dlaczego wybrać akurat ten?

  • Chcesz wiedzieć do jakiego pakietu należą Twoje pliki?
  • Chcesz odinstalować oprogramowanie, które nie ma make uninstall?
  • Przeszkadzają Ci programy z ustawianym za Twoimi plecami setuid root?
  • Nie podoba Ci się, że pakiety po cichu nadpisują podczas instalacji pliki innych pakietów
  • Nie lubisz menadżerów pakietów takich jak RPM?
  • CHCESZ MIEĆ CAŁKOWITĄ KONTROLĘ UŻYWAJĄC JEDYNIE WBUDOWANYCH WŁAŚCIWOŚCI UNIXA?

Jeśli tak, to może zaciekawi Cię ten sposób zarządzania oprogramowaniem.

Użytkownicy i grupy są podstawowymi składnikami systemów unixowych. Od dawna są z powodzeniem wykorzystywane do monitorowania kto utworzył plik i kontrolowania kto jest uprawniony do jego usunięcia lub zmiany. Jednakże ta kontrola jest nałożona tylko na pliki zwykłych użytkowników. Co za marnotrawstwo!. Proponuję rozszerzyć tą kontrolę na wszystkie pliki w systemie.

Ogólną ideą jest utworzenie użytkownika pakietu np. konto użytkownika z ograniczonymi prawami do budowy i instalacji oprogramowania zamiast wykonywania tych zadań jako root. Pozwoli to nie tylko uzyskać pełniejszą kontrolę nad tym co skrypty mogą lub nie w zakresie budowy i instalacji, lecz również dostarczy bardzo przydatny system zarządzania pakietami.
Przykładowo gdy chcemy zbudować i zainstalować pakiet exim to najpierw dodajemy do systemu użytkownika exim a później z jego konta przeprowadzamy proces kompilacji i instalacji.

To wszystko może wydawać się zniechęcające i sprawiać wrażenie skomplikowanej metody, powodującej sporo problemów i ogólnie za bardzo problematycznej dla każdego oprócz prawdziwego, hardcorowego admina mającego doświadczenie w programowaniu. Nie jest to jednak prawdą. Po pierwsze wiele z sytuacji w pracy z metodą ‚package user’ wyglądających jak problemy instalacyjne są de facto pożądanymi funkcjonalnościami. Jeśli ‚make install’ kończy się błędem dla jakiegoś pakietu ponieważ próbuje zainstalować plik o tej samej nazwie jak już istniejący, lecz należący do innego pakietu nie powinieneś kląć, że musisz spędzić dodatkowy czas na rozwiązanie tego problemu. Zamiast tego powinieneś być szczęśliwy, że zostałeś ostrzeżony o tej kolizji nazw. W przeciwnym przypadku, gdyby zostało niezauważone, mogłoby namieszać w mniej lub bardziej subtelny sposób w systemie. Po drugie system ‚package user’ nie jest podejściem wszystko-albo-nic. Działa na pojedynczych pakietach. Jeśli pakiet sprawia zbyt wiele problemów zawsze możesz się poddać i dokończyć instalację jako root. No i wreszcie istnieją skrypty dostarczane w archiwum more_control_helpers automatyzujące wiele aspektów instalacji oprogramowania tą metodą.