Masowe zmiany

[Tomasz Kłoczko]

Chyba już koniec bardziej masowyc zmian związanych z użyciem makr zamiast
ścieżek wprost. Po tym wszystkim może się okazać, że dany spec jest
chwilowo nie do użytku i że te półautomatycznie zmiany trzeba będzie jakoś
jeszcze poprawiać ręcznie .. no cóż.
Kolejna sprawa jaką dobrze by było wykonać przy okazji teraz kompletowania
speców konstruowanych wg nowego sposobu wynika z tego, że teraz spece już
w małym stopniu przypominają pierwowzory. Propozycja jest taka, żeby z
tego powodu poobcinać wpisy w %changelog robiąć tylko któtkie
podsumowanie:

- based on: "RH spec"|"RH contrib spec"| ....
- pl translation maked by: ..

ewentualnie jekieś inne wpisy które komuś pzryjdą do głowy, które moga
mieć charakter podumowujący.

Także od jutra (ja idę już spać dzisiaj .. Artur Ty też się wreszcie
wyśpij ;) można po kolei już brać spece na stołki i dopracowywać. W razie
gdyby jeszcze wynikły jakieś zmiany ujednolicające związane z użyciem makr
to proponowałbym wykonywać je także hurtem tak coby co najwyżej poprawiać,
a nie szukać czy wszystkie wystapienia jakiś ścieżek są zgodne z ogólnym
schematem.
Po skończeniu całości powinniśmy uzyskać dość ciekawe pakiety, któtre
zupełnie przy okazji powinny być dość dobrze przenoszalne między PLD, a RH
na poziomie src.rpm.
Kolejna sprawa jaką już zauważam, to to, że używanie makr wpływa jednak na
polepszenie ciut przejrzystości, a niektóre niezgodności z rozłożeniem
plików względem FHS są jakby lepiej widoczne.

To wszystko (zmiany z użyvciem makr w specach) to jest inwestycja w
przyszłość. Powinno to nam pozwolić odsunąć zapewne o kilka setek pakietów
dalej granicę przy której panowanie nad zawartościa całej masy pakietów w
sumie będzie o wiele cięższe niż np. obecnie, co w sumie powinno dać tyle,
że łatwiej powinno dać się zgromadzić duży zestaw poprawnie
skonstruowanych pakietów w porównaniu do innych greup zajmujących się
kompletowaniem pakietów do innych dystrybucji. Także używanie makr zamiast
ścieżek wprost powinno wpływać na ewentualne przyszłe manipulacje prefixem
instalacji pakietu, o ile przyjdzie nam kiedyś taki pomysł. IMHO także
używanie makr powinno ułatwić konstrowanie generatorów spedów czy to z
tego co powstaje z "make install" w jakieś oddzielone drzewko czy też może
na podstawie plików Makefile.am o ile zródła wykorzystują
automake/autoconf czy z opisów modułow perlowych czy jeszcze innych
regółarnie ułożonych gróp pakietów zródłowych.

I jeszcze raz .. napewne zmiany ostatnich dni wpłyną na to, że w
najbliszym okresie będziemy mieli lekki bałagan. Niemniej w skali
dłuższego czasu powinno się to zwrócić z nawiązką.

Przy okazji tych zmian praktycznie każdy pakiet będzie musiał być
faktycznie przynajmniej raz przebudowany co i tak przy przejściach na nowe
glibc/kernel/rpm-a by musiałoby mieć miejsce. Tak to wszystkie istotne
zmiany powinniśmy mieć skumulowane w pojedynczą falę po której przejściu
dalsza praca powinna być już jednak łatwiejsza.

Jeszcze nie wiem jak będzie wyglądał tryb w związku z tym wypuszczania
kolejnych poprcji pakietów ale to wyjdzie w prawniu.

Mam nadzieję, że także przy okazji tych zmian pierwsza porcja pakietów
będzie już wieloarchitekturórowa (w ramach x86), a także da się już
uruchomić pierwszą wersję tranzakcyjnego budowania pakietów na kilku
maszynkach. Tak czy inaczej na jeszcze kilka dni lekkiego stanu
nieustalonego trzeba być przygotowanym (myślę, że do końca tygodnia da się
jednak z tymi zmianami uporać, po to żeby potem robić już płynniej podług
nieco zmienionych zasad).

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*