Szukam zajecia

[Tomasz Kłoczko]

On Thu, 2 Sep 1999, Artur Frysiak wrote:

> [czwartek, 02 wrzesień 1999], Robert Slaski napisał(a):
> 
> > Artur Frysiak wrote:
> > > 
> > > Gdy jest to uzasadnione :-)
> > 
> > A kiedy jest? :-)
> 
> Kiedy instalowanie całego pakietu w 'pełnym wypasie' obliguje instalowanie
> wielu innych pakietów a możliwe jest taki podział pakietu aby pakiet główny
> miał podstawową funkcjonalność a reszta przychodziła by w miare dokładania
> następnych podpakietów.
> Patrz newt.spec, postgresql.spec i inne.

(Będzie dość długo ale jest trochę faktodrobnicy którą warto tu także
nieco naświetlić)

Jakiś czas temu w rpm-ie było planowane dołożenie kolenych klas plików i
dołożenie mechanizmów ich obsługi (z linnii poleceń i w librpm). Widać
trzeba będzie ten temat na rpm-list odświezyć. W tej chwili są tylko dwie
klasy plików zwykłe i dokumenty. Z tym, że w klasę dokumentów
automatycznie wpadają many, info i to co jest zaznaczane jako %doc i to
jest z lekka w kilku przypadkacj niewygodne. I z kakietu pliki
podstawowemuszą być zainstalowane, a dokumenty moga być pominięte przez
--excludedoc czy makro w rpmrc.

IMHO wydzielanie pakietu doc w obecnej chwili jest uzasadnione tylko w
kilku przypadkach (jakie ? .. podał Artur). Co do reszty to IMHO wydzielać
nie ma jedank co, a nawet w przypadku dojścia wreszcie porządnej
rozszeżonej obsługi klas plików w pakietach i obecne podpakiety doc będą
mogły zniknąć (obecnie wydziela się je dlatego żeby mieć many, a nie mieć
dodatkowej dokumentacji, która w tych kilku przypadkach przerasta swą
objętością znacznie many). Jakby poprzypominać i pomarudzić na rpm-list o
tym temacie to zapewne możnaby to mieć w rozsądnym czasie.

Co do sytuacji kiedy chce się przeczytać dokunetację bez instalacji. No
cóż można to zrobić w każdej chwili .. wystarczy poprostu wypakować
dokumentację z pakietu choćby za pomocą mc jeżli ktoś nie potrafi sie
posłużyć rpm2cpio czy też mu sie nie chce z tehgo programu korzystać :)
Przecież pakiet to też archiwum do pewnego stopnia podobne do tara czy
innych.

Co do samych klas to miałoby to wyglądać tak, że np. oprócz klasy doc są
jeszcze np. man, info i dzięki temu że bedzie przy instalacji możliwość
pominiecia konkretnej klasy/klas będzie można mieć pakiet np. apache z
pełną dokumentacja w jednym pakiecie bez koniecznosci uciekania sie do
trików z podziałem pakietu.

Przy istnieniu mechanizmów klas możnaby zresztą unikać tego co jest
robione obecnie czyli dzielenia pakietów w wielu przypadkach. Np. zamiast
static i devel możnaby mieć klasy plików static i devel i wrecz może
nawet devel-doc co też zmniejszałoby ilość różne pomyłek co do instalacji
pakietów nie tej wersji co trzeba.

Może to sie wydać nieco nieporęczne lub nie przejrzyste ale w sytuacji
kiedy ilość pakietów może już tylko rosnąć dołożenie możliwości
traktowania pakietu jako pewnej paczki z "przegródkami" (które w obecnej
chwili są w ilości sztuk jedna i to w postaci niemal szczątkowej) całość
mogłaby na dłuższą metę zyskać tylko na elastyczności i przejrzystości tak
jak z możliwością oznaczanai plików makrami %lang co widać już, że przy
braku tego mechanizmu w np. deb powoduje całkiem spory rozrost ilosci
pakietów (pakiety z manami narodowymi, pakiety ze słownikami do ispella,
pakiety z innymi narodowymi dodatkami (szczególnie japończycy ostatnio tam
mieszają) do różnych pakietów). W obecnej chwili zamiast np. pakietów
howto-<lang> wypadałoby zrobić w zasadzie jeden duży pakiet z oznaczeniem
różnych zasobów różnymi %lang. Choć w tym skrajnym przypadku akurat moze
to być jeszcze dyskusyjne ze względu na to że obecnie wszystkie howto mają
ponad 90MB ale jak uwzględnić to że z jednego src mogłby powsztć rególarne
howto, howto-ps, howto-sgml, howto-html gdzie w obecnej formie w
howto-polish jest wszystko wymieszane i tylko pakiet z dokumentacją eng ma
czysty podział to w sumie objętość paietów wynikowych powuinna jednak w
sposób odczuwalny sie zmniejszyć.

Tak czy inaczej z wydzielaniem pakietów doc raczej bym sie wstrzymywał
próbując jednocześnie przypominac o temacie klas na rpm-list.

Tak jak napisałem .. zamiast traktować pakiet jako niepodzielną część (do
czego ze względu na nie stosowanie %lang przywyczajają nas wszystkie
dystrybucje na około, a także i Debian w którym w opisie pakietu nie mam
takich mozliwości) trzeba sie zacząć przywyczajać, że ma on w sobie
możliwości wydzielania części i że jest on tylko kolejnym poziomem
hierarhi wyboru własności gdzie podział może przebiegać po liniach
wyznaczanych zależnościami narodowymi (oznaczenie plików makrami %lang) i
funkcjonalnumi (klasy z oznaczaniem grup plików makrami %class %endclass
czy %group %endgroup). Poprostu dużo ilość obecnych pakietów możnaby tak
naprawdę próbować dzielić jeszcze na mniejsze fragmenty ale powyżej pewnej
ilość wynikowych produktów zamiast pomagać będzie to już tylko stawać się
przekleństwem, a w sytuacji jak już wspomniałem wzrostu ilości pakietów
(constantly) raczej należałoby unikać tego dzielenia ograniczając się
tylko do tego co w danym momencie jest nprawdę niezbędne. I o ile klasy
wreszcie się pojawią to będzie można IMHO napowrót pakiety raczej łączyć
niż dzielić (choćby scalając pakiety z bibliotekami).

Wydaje mi się, że wiedzą, że w zasięgu ręki można mieć klasy plików w
pakiecie i zdając sobie w pełni znaczenie z istenienia makra %lang i tego
jakie mozliwości ono wyznacza nie musimy iść za trendem dzielenia pakietów
tak jak to jest w innych dystrybucjach gdyż prędzej czy później trend ten
będzie zaniechany. Mając tą wiedzę można w tym momencie o wiele
ekonomiczniej zaplanować rozwój pakietów który w przypadku dystrybucji
które nie przyjmą powyższego do wiadomości wybrnięce w tej mody będzie bąć
kosztowne bąć niemożliwe do przeprowadzenia bez szarpamnia się w
dyskusjach ze względu na przyzwyczajenia jakie ten styl wytworzy u ludzi
użytkowujacych pakiety.

W tym sensie obecne np. wydzielanie pakietów static (przyznaję się) to
jest jeszcze nadal poddawanie sie temu trendowi. Niemniej chyba pora jest
właśnie żeby na całe to poletko spojrzeć z nieco innej perspektywy po to
zeby nie utracić nad tym kontroli w momencie kiedy pojawia się głos o
dalsze dzielenie i obecnie warto bedzie IMHO przeboleć wydzielanie tych
podpakietów po to żeby za jakiś czas nie cofać tych zmian które w gruncie
rzeczy aż tak dużo (relatywnie do wagi innych zmian) nie zmieniają.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*