Smerovanie RH [Was: Re: bw]

[Milan Kerslager]

On 21 Oct 2000, Stanislav Meduna wrote:

> Vsetky readme na sieti hovoria, ze libGL.so by mal
> v XFree86 byt. U mna vsak nie je. Dovod?
> 
> %install
> ...
> # Clean out Mesa stuff
> rm -f $RPM_BUILD_ROOT/usr/include/GL $RPM_BUILD_ROOT/usr/lib/*
> rm -rf $RPM_BUILD_ROOT/usr/X11R6/include/GL
> rm -f $RPM_BUILD_ROOT/usr/X11R6/lib/libGL* \
>         $RPM_BUILD_ROOT/usr/X11R6/lib/libOSM* \
> ...
> %changelog
> * Wed Jul 18 2000 Bill Nottingham <notting na redhat.com>
> - remove Mesa (use its own separate package for easier updating)
> 
> OK, uznavam, ze to asi ma zmysel. Lenze a) v ziadnej dokumentacii
> o tom nie je zmienka (README.DRI a.p. uz akosi patchnut zabudli),
> b) asi by bolo lepsie sa dohodnut s autormi XFree86 na cistom
> oddeleni OpenGL, c) porusili "the principle of least surprise" -
> pouzivatel ocakava, ze patche opravuju bugy alebo pridavaju features,
> ale malokto ocakava, ze patch zrusi kus funkcnosti baliku.
> 
> Vysledkom sucasnej situacie je, ze nestaci povedat "mam XFree86 4.0.1",
> ale treba povedat "mam RH 7.0". Neviem, ci je to ta spravna cesta.

To je zase demagogie, protoze je naprosto normalni, ze balicky jsou treba
rozdelene na glibc a glibc-devel (a nikdo nepozaduje rozdeleni na urovni
puvodniho baliku GLIBC). Nema to jen RH a slouzi to k tomu, aby se
instalovalo jen to, co skutecne clovek potrebuje (a ne vsechno, co nikdy
clovek ani nepouzije). Rekneme, ze lze vytknout, ze se to nefunguje (bud
ze se to nenainstaluje nebo ze to nechodi vubec). Ale ma to takovy hacek -
me se XFree86 posledni dobou moc chodive nezda a sam se divim, jak se to
dari udrzet v provozuschopnem stavu (pro co nejvic pripadu obycejnych
uzivatelu).

Co se tyka patchovani ruznych produktu, tak se taky nikdo nedivi, ze SuSe
ma ReiserFS v jejich kernelu, stejne jako se nikdo nedivi, ze nektere
balicky jsou v distribucich (na rozdil od "originalu") opravovany (i kdyz
je to v pripade dlouhodobejsiho stavu nesystematicke). Obcas je to
nutnost, protoze autori "originalnich" balicku uz neexistuji, nereaguji
nebo *nechteji* reagovat. Pak zbyva uz jen filozoficka otazka, zda v
distribuci pouzit identicke cislo verze (i kdyz produkt je velmi odlisny)
a riskovat zmateni ve stylu Babylonu nebo pouzit radeji vyrazne jine cislo
a zarucit tak, ze vsichni budou vedet, na cem jsou. Ti co me nebo RH
obvinovali z ruznych nekalych praktik by si zde meli vsimnout, ze v tom
prohlaseni se jasne rika, ze 2.96 je "code-name for our development branch
that will eventually become GCC 3.0", coz vyvraci teorii o tom, ze by si
RH zavedli toto cislo ze sve vlastni libovule (viz:
http://gcc.gnu.org/gcc-2.96.html), takze v distribuci je jednoduse
aktualni CVS + patche zarucujici funkcnost baliku (nyni je jiz najdeme v
CVS).

Proto si osobne myslim o GCC tymu svoje (proc asi vzniklo tisic a jeden
klon - nebylo to nahodou proto, ze "mainstream" byl nepruzny?). Podobna
situace je i u jinych produktu. Take zde propagovane prohlaseni GCC teamu
o "development" verzi, ktera "se nedoporucuje k pouzivani" je silne
alibisticke - vsimete si, kolik development baliku se normalne pouziva
(protoze jednoduse nic lepsiho neni). Take v tom prohlaseni je jasne
napsano, ze kompatibilta na urovni C bude, coz celou dobu tvrdim a take to
RH tak vzdy propagovali (nebo ze by nekteri neumeli cist?).

Co se tyka DRI a dalsich v XFree86 radoby podporovanych rozsireni - behem
vyvojoveho cyklu 7.0 a Beta testovani nekteri vyvojari pracujici pro XFree
spolupracovali pri upravach pro ruzne graficke karty. Bohuzel co nekterym
fungovalo, jinym nepracovalo i pres vseobecnou snahu - zde tedy
jednoznacne obraceny pripad, kdy stable balik vykazuje unstable chovani.
Pres to si myslim podarilo spojenim 3.3.6 a 4.0.1 vytvorit v soucasne dobe
vseobecne nejprijatelnejsi reseni (vcetne ruznych oprav) - berte ohled na
to, ze 7.0 je obrazem toho, co bylo aktulani na konci prazdnin - dnes muze
byt situace jina a na bezchybnost cehokoliv asi neveri nikdo.

--
                        Milan Kerslager
                        E-mail: milan.kerslager na spsselib.hiedu.cz
                        WWW:    http://www.spsselib.hiedu.cz/~kerslage/