Z tą taczką dłużej czekać już nie można ..

[Tomasz Kłoczko]

czyli kolejna porcja nowych pakietów.

ImageMagick-4.1.0-5

	Tutaj downgrade do wersji dającej epoprwne efekty przy konwersji
        tga -> gif i tga -> jpg (tu też były jaja).

audiofile-0.1.6-1, automake-1.4-4, gtk-engines-0.5-1, guile-1.3-4,
libcap-0.122-2, lilo-0.21-3, m4-1.4n-3, libtool-1.2d-2, libgr-2.0.13-16,
kibble-0.7.2-1, less-332-5, file-3.26-4, cpio-2.4.2-12, dia-0.30-1,
mc-4.5.24-1, qt-1.43-1, libxml-1.0.0-1, libgtop-1.0.1-1, imlib-1.9.4-1.

	Kosmetyka i/lub update do ostatniej wersji i/lub zmiany w Group,
	i/lub dodane "Conflicts: glibc <= 2.0.7", usunięta grupa man z
	stron manowych, i/lib pousuwane niepotrzebne requires.

	Z powyższego warto przyjrzeć się dia. Robi się z tego dobre
	narzędzie do wektorowej edycji diagramów.

lesstif-mwm-0.87.1-2

	Poprawki z %doc w /home/http. Wersja 0.87.9 nie za bardzo chce się
	instalować wg dotychczasowej procedury .. 0.88 jeszcze nie
	próbowałem ale też zmiany nie są jakieś wielkie zeby przejście na tą
	wersję było tu śpieszno.

Jeszcze pewna uwaga apropo rpm 2.9.x.

Otóż zastosowano tu w findrequirs, findprovide pewiem trik który osobiście
mi sie nie za bardzo podoba ale wychodzi na to, że jednocześnie on
rozwiązuje sprawy związane z przejściem na glibc 2.1. Otóż do dependences
dodawane są symbole libc.so.6(Version References) z czego powstają np.:
libc.so.6(GLIBC2.1), libc.so.6(GLIBC2.0). W obecnej sytuacji jest to co
prawda chyba jedyny sposób automatycznego rozpoznania glibc 2.1 bo w
binarkach libów generowanych z glibc 2.1 pole Version References jest
akurat wypełniane. Jakoś nie wiem dlaczego poprostu nie zmieniono SONAME
liba na coś wyższego (choćby lib*.so.6.1) i chyba dlatego jakoś nie jestem
do powyższego przekonany.

Tak czy inaczej przejście na rpm 2.9x (ostatni to 2.92) wiąże się z dość
użymi zmianami. Także zmianie ulega (w stosunku do tego co mamy obecnie w
devel i stable) format bazy db (powrót do db1). Na dłuższą metę jest to
pozytywne gdyż przy przejściu z RH 5.x nie powoduje konieczności mieszania
prezy bazie i tutaj nie ma co się boczyć na tą zmianę.

W sumie nie za bardzo moge jakoś podjąć rozsądną decyzję o przejściu teraz
czy później na nowego rpm-a. Z jednej strony nowe możliwości i usunięcie
pewnych niedogodności, a z drugiej to, że w zasadzie takie zmiany dobrze
byłoby wykonywać jednym ruchem czyli w momencie kiedy ma się już pewną
masę krytyczną pakietów po to żeby przejście wykonać niemal jednym ruchem.
jezeli ktoś w związku z powyższym .. jeżeli ktoś miałby jakieś
uwagi/sugestie które mogłyby zadecydować o wykonaniu takiego przejścia jak
najszybciej lub w nieco dalszej perspektywie to prosiłbym o drobną
dyskusję na ten temat.

kloczek
PS. Sergiusz .. chyba trzeba by wysłać na pcol info o zmianch adresów
list.
-- 
-----------------------------------------------------------
*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*