Oryginalnie strona ta rozpoczynała trzecią serię tekstów "o budowaniu pakietów RPM". Podchodzę nieco niepewnie do niej, bo... Gdy zaczynałem pisać pierwszą serią, udumałem sobie prosty rozkład: napiszę trylogię, część pierwszą o składni i podstawowej ideologii, drugą bardziej praktyczną, no i trzecią w której wymienię jakieś bardziej ogólne uwagi, których nie byłem w stanie sensownie wpleść w fabułę dwóch poprzednich tomików.

Ale minęło już tyle czasu odkąd postawiłem ostatnią kropkę w części drugiej, że sam nie wiem co miałem zamiar tutaj napisać. Nie mam pomysłów, pozapominałem już. Niepotrzebnie zrobiłem sobie taką długą przerwę. Ale OK, zrobię to tak: zacznę pisać o pierwszej rzeczy która mi przyjdzie do głowy, a potem może jakoś, poprzez skojarzenia i nawiązywanie, to się potoczy. Ten tomik może okazać się bardziej wodolejny i przegadany niż poprzednie, może też "wyjść" dużo bardziej techniczny. Hihi, w taki sam sposób napisałem swoją maturę :)

W każdym razie ten tomik będzie na pewno ostatnim w tej serii.

OK, więc zapewne masz już podstawy pozwalające ci budować pakiety RPM. To dobrze. Teraz nie musisz już tak bardzo przejmować się zastanawianiem nad tym, jakimi środkami możesz osiągnąć cel - możesz zacząć szlifować technikę ;)

Nie ma jednego, uniwersalnego sposobu na budowanie pakietów. Liczy się tak naprawdę tylko rezultat. Zwłaszcza jeśli robisz pakiety tylko na swoje potrzeby, lub na potrzeby małej sieci - gdzie to ty jesteś administratorem. Oczywiście są pewne rzeczy, pewne problemy, które można rozwiązać na wiele sposobów - przy czym któryś ze sposobów będzie zawsze uważany za "bardziej elegancki" niż inne. Ale w bardziej ogólnych sprawach masz wolną rękę. Dlatego możesz sobie wyznaczyć pewne priorytety, do których będziesz przykładał większą wagę. Ignorując zupełnie inne kwestie.

Nie wiem co będzie dla ciebie najważniejsze, nie chcę też w żaden sposób niczego ci narzucać - ale może objaśnię nieco poprzedni akapit na swoim przykładzie, porównując np. pakiety które ja sobie buduję z tymi które produkują developerzy PLD (nie, to nie ma być chwalenie ani ganienie żadnej ze stron, po prostu pakietom PLD regularnie się przyglądam, jako że chyba z wszystkich dystrybucji to właśnie w PLD robi się najlepszy użytek z funkcji oferowanych przez RPM - nawet w RH, kolebce RPM, nie wykorzystuje się tego narzędzia w tak pełny sposób). Ale wracając do właściwego tematu - w PLD daje się łatwo zauważyć np. wielojęzyczność pakietów - opisy pakietów, ich kategorie - wszystko to jest przetłumaczone na kilkanaście języków, w każdym pakiecie. Podobnie z plikami tłumaczeń dla programów czy stronami manuali. Wiadomo, PLD to dystrybucja, nie wiadomo jakiej narodowości będą użytkownicy. Ale ja nie muszę tego robić - mojego systemu używają tylko osoby dobrze mi znane. Więc nie muszę się bawić w pisanie wielojęzycznych opisów. O, albo podział oprogramowania na mniejsze paczki - PLD, jak i inne dystrybucje, dzieli pakiety według klucza xxx-libs i xxx-devel, dodatkowo niektóre większe projekty (np. Perl czy XFree86) są dzielone na dodatkowe, mniejsze jeszcze komponenty, np. w XFree86 będą to poszczególne rodzaje fontów, sterowników do różnych kart graficznych itp. Cudowne w dystrybucji, bo pozwala użytkownikom o różnych wymaganiach skompletować sobie tylko te niezbędne im paczki, pomijając inne, zbyteczne (np. Niemiec nie będzie miał zapewne potrzeby instalowania fontów iso-8859-2). Bardzo fajne w dystrybucji, ale całkowite marnowanie czasu w pakietach "na osobisty użytek". Ja zwykle dobrze wiem już w momencie budowania pakietu co też będzie mi potrzebne. Mogę pousuwać zbędne mi pliki, dokumentację, części programu - często tworząc pakiet dużo mniejszy niż ten z dystrybucji. Do tego mam mniej pakietów zarejestrowanych w systemie, bo każdy pakiet staje się odrębną całością (np. całe XFree86, w konfiguracji jakiej potrzebuję, mam w jednym, jedynym pakiecie - a nie w osiemnastu pomniejszych pakietach połączonych siatką zależności).

Ja często rezygnuję z tzw. i18n, gdy "locale" (np. pliki tłumaczeń) są niekompletne lub złej jakości - operowanie w aplikacjach anglojęzycznych nie jest dla mnie problemem. Oczywiście w dystrybucji nie można sobie na to pozwolić, ale ja mogę. I pozwalam sobie. Dystrybucje powinny mieć hiper-poprawne pakiety, co oznacza że pakiet źródłowy powinien dokładnie opisywać wszystkie swoje zależności, zwłaszcza te wymagane przy budowaniu (BuildRequires:) - ja tego robić nie muszę, bo znam swój system na tyle dobrze, by wiedzieć że zawsze mam kompletne środowisko developerskie - dlatego nie muszę umieszczać w zależnościach np. autoconfa czy gcc, bo przecież jestem świadomy, że te narzędzia są niezbędne. Ale robię to tylko dlatego, że buduję pakiety dla siebie - nie oznacza to w żadnym wypadku niechlujności, tego nie można powiedzieć. Po prostu pomijam części dla mnie zbyteczne. Ktoś inny może mieć oczywiście inne priorytety.

Dodatkowo mam kilka innych "bzików" które objawiają się w różnych sytuacjach. Np. z uporem maniaka redukuję dokumentację info w każdym pakiecie do pojedynczych, wielkich plików info (zamiast dziesiątek mniejszych, np. jeden gcc.info zamiast gcc.info-1, gcc.info-2 itp.). Z niechęcią podchodzę do dokumentacji w /usr/share/doc, zwykle ją usuwając z pakietów, chyba że jest naprawdę dobra (np. dokumentacja mutta czy slrn). Wycinam z pakietów części, których na pewno nie będę używał (np. online-help gimpa). Kompiluję programy z często dziwacznymi przełącznikami. Ogólnie to wszystko podpada pod jedno "schorzenie" - staram się jak najbardziej system ściągnąć "w sobie", realizując tytułową kontrakcję. Oznacza to pakiety dopasowane jak najbardziej do pracy z sobą, z oszlifowanymi krawędziami, skompilowane tak, by zajmować jak najmniej miejsca i pamięci operacyjnej (bez zagrażania jednak wydajności). Pakiety okrojone ze zbędnych modułów - znowu, redukcja rozmiaru. To jest mój główny priorytet i odstępuję od niego niezmiernie rzadko. Skoro już doszedłem do tego niewątpliwie bardzo ważnego punktu ;) i zająłem stanowisko, mogę zaprezentować kilka środków których można użyć aby zrealizować ową "kontrakcję". Jeszcze raz: to moje, osobiste nastawienie. Jeśli będziesz uważać to, co wyłożę za stratę czasu - to nie martw się, wcale nie musisz być od razu szalony - każdy ma pełne prawo mieć swoje, własne priorytety. To taka zaleta bycia linuksiarzem - jest jeden główny nurt, ale rzeka jest na tyle szeroka, że wykształca się w niej wiele "wariacji", nawet nurtów wstecznych - tak że każdy znajdzie swoją niszę.