Założenia dotyczące tworzenia i rozwoju PLD

Tworzenie i rozwój PLD

Założenia:

  • używanie FHS 2.x jako specyfikacji struktury katalogów,
  • całkowite odejście od termcap i libtermcap (w PLD nie ma pakietu z libtermcap i samego termcapa; ani jeden pakiet nie jest związany z termcapem),
  • ujednolicenie gospodarki inet serwisami. W praktyce jest to realizowane poprzez używanie tego co oferuje rc-inetd: jest to bardzo prosty mechanizm, przy tym o wiele bardziej elastyczny od tego, co można znaleźć w konkurencyjnych dystrybucjach,
  • pełne przygotowanie pakietów do automatycznego uaktualnienia. Pakiety z RH kompletnie nie są na to przygotowane. Przygotowanie to wiąże się to z restartowaniem serwisów przy ich uaktualnieniu, odpowiednim przygotowywaniem procedur uaktualnienia w taki sposób, by umożliwić automatyczną aktualizację nawet przy zmianie plików konfiguracyjnych,
  • brak nastawienia na używanie tylko wybranych aplikacji w danej klasie (np. wśród MTA i różnych innych usług). Założenie jest takie, że w najprostszej wersji istnieją preferowane pakiety (np. finger daemona), ale w praktyce w systemie ma być to, czego sobie użytkownik zażyczy (w przypadku fingerów jest to już sprawnie przygotowane; jest jeszcze kilka innych grup takich aplikacji),
  • używanie iproute2 jako podstawowego narzędzia do operowania na interfejsach sieciowych, dzięki czemu np. skrypty startowe z PLD są prostsze i krótsze mimo większej funkcjonalności w stosunku do swoich odpowiedników z RH; inną zaletą jest wsteczna kompatybilność z opisem interfejsów sieciowych z tym, co jest stosowane w initscripts z RH; kolejną cechą skryptów startowych jest to, że — w zależności od preferencji użytkownika — mogą one wyświetlać wszystkie komunikaty po polsku,
  • brak nałożonych z góry ograniczeń co do zestawu pakietów, jakie mogą być w dystrybucji. W praktyce oznacza to, że użytkownik ma do dyspozycji wszystko, co udało się nam zebrać, Jeżeli coś zostanie opracowane i przystosowane do tego, żeby mogło współgrać z resztą pakietów, to znaczy, że komuś było potrzebne, więc może komuś przydać się w przyszłości,
  • przystosowanie do łatwego przejścia systemu na alternatywne metody autoryzacji (i — w zależności od potrzeb — szyfrowania) komunikacji po sieci, jak PAM, czy GSAPI, TSL/SSL… Jest bardzo prawdopodobne, że już w niedługiej perspektywie dużą rolę zacznie tu odgrywać SASL. W praktyce owo łatwe dostosowywanie do np. kerberyzacji systemu jest realizowane także z użyciem rc-inetd, która to platforma ułatwia znakomicie podmianę różnych serwisów na wersje skerberyzowane czy też wykorzystujące inne mechanizmy jak np. socks5 (tutaj jeszcze jest mało zrobione, ale furtka jest szeroko i jednoznacznie otwarta),
  • uzupełnianie opisów i dokumentacji w różnych językach. W dużej części robi się to niejako przy okazji. Użytkownik może sobie skonfigurować i zainstalować wybrane oprogramowanie ze wsparciem dla preferowanego zestawu języków, np.: angielski i niemiecki czy też angielski i polski (zasoby dla innych języków zostaną pominięte). Tak unikalną możliwość konfiguracji osiągamy dzięki konsekwentnemu oznaczaniu zasobów narodowych makrem %lang() w poszczególnych pakietach.
  • maksymalna automatyzacja różnych powtarzalnych czynności (dotyczy to zarówno metodologii bieżącej pracy jak i zawartości pakietów).
READ  Co w zamian Ubuntu Unity?

Wiele założeń wynika bezpośrednio z procedur przygotowywania pakietów, jak:

  • pakowanie wszystkich plików dokumentacji z użyciem gzip (bzip2 nic w praktyce tu nie wnosi, a dostarcza tylko nowych kłopotów, czego doświadczają od czasu do czasu użytkownicy Mandrake),
  • separacja bibliotek statycznych w osobne podpakiety *-static (nie każdy tego potrzebuje)
  • stripowanie bibliotek współdzielonych (debug info w razie potrzeby jest w bibliotekach statycznych).

Pozostałem założenia dotyczą metodologii pracy:

  • używanie CVS jako usługi służącej do przechowywania bieżących zasobów,
  • preferowany format źródłowy dokumentacji to SGML/docbook.