PLD 1.0 beta 1: nowe iso na ftp

[Tomasz Kłoczko]

On Thu, 1 Aug 2002, Andrzej Krzysztofowicz wrote:

> > 
> > > W sumie racja że sprawa jest nieco kontrowersyjna i mało jednoznaczna.
> > 
> > Tym niemniej, nalezaloby wypracowac jakis konsensus, zeby nie grac w
> > ping-ponga...
> 
> OK, kloczek jest "a bit busy", wiec moze ja zreferuje na czym stanelo
> odnosnie polityki w tej kwestii (beda pewne zmiany), i co nalezaloby
> potraktowac jakio punkt wyjsciowy do dyskusji:
> 
> 1. Srodowisko budowania powinno w sposob jednoznaczny definiowac pakiet
>    [tu moze byc problem obecnosci/nieobecnosci pakietow, ktore w jakis
>     sposob wpadaja do Requires - rozwiazywanie nazw - ale patrz nizej]

Nieco inaczje to sformułuję:
- lista BuildRequires powinna jednoznacznie określać istotne własności 
  build środowiska

- powinna być pozbawiona elementów redundantnych. Przykłady: jeżeli już
  jest np. libglade-devel czy gnome-libs-devel to już nie ma po co 
  umieszczać gtk+-devel; jeżeli juz jest SDL_mixer-devel to nie ma po co 
  umieszczać SDL-devel. Żeby to diząłało niewątpliwie trzeba dbać o listy 
  nazw pakeitów jakie wpadają w Requires w pakeitach devel

- lista BR powinan być możliwie krótka.

> 2. Docelowo, aby zmniejszyc rozmiar bazy chcemy wyeliminowac rozwiazywanie
>    m.in. perl(...) -> nazwa-pakietu w stosunku do automatycznych i recznych
>    Requires.

Tutaj chodzi o coś podobnego ale jednocześnie innego. Otóż mamy obecnie 
ponad 4.5K pakietów wynikowych, a będzie ich wiecej. Spora ilość powiązań 
w Requires jest nadmaitrowa. możnaby bardzo mocno pzreżedzić graf 
zależności i nadal lista zależności w poszczegółnych pakeitach 
jednoznacznie definiowałaby topologię takiego grafu.
Nadmiarowość regół wiażących pakiety jest sporai i zapewne moznaby ją 
efektywnie skrócić i nic by się nie stało. Przykład tego co
możnaby ciąć:

$ rpm -q --requires gnome-libs
/sbin/ldconfig  
/sbin/ldconfig  
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
/bin/sh  
libICE.so.6  
libIIOP.so.0  
libORBit.so.0  
libORBitCosNaming.so.0  
libORBitutil.so.0  
libSM.so.6  
libX11.so.6  
libXext.so.6  
libXi.so.6  
libXpm.so.4  
libaudiofile.so.0  
libc.so.6  
libc.so.6(GLIBC_2.0)  
libc.so.6(GLIBC_2.1)  
libc.so.6(GLIBC_2.1.3)  
libc.so.6(GLIBC_2.2)  
libdb-3.1.so  
libdl.so.2  
libesd.so.0  
libgdk-1.2.so.0  
libgdk_imlib.so.1  
libglib-1.2.so.0  
libgmodule-1.2.so.0  
libgtk-1.2.so.0  
libjpeg.so.62  
libm.so.6  
libm.so.6(GLIBC_2.0)  
libpng.so.2  
libutil.so.1  
libutil.so.1(GLIBC_2.0)  
libwrap.so.0  
libz.so.1  
ORBit  
XFree86-libs  
audiofile  
db3  
esound  
glib  
glibc  
gtk+  
imlib  
libjpeg  
libpng  
libwrap  
zlib  
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadIsBzip2) <= 3.0.5-1

$ rpm -q --requires gnome-libs | wc -l
     51

Ptóż z powyższego mogłyby wypść: libutil.so.1, libm.so.6, 
libc.so.6(GLIBC_2.1.3), libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.0) 
libc.so.6. czyli sześć elementów. Kolejne 13 to nzawy pakietów. W sumie 
zbliza się to do 40% listy.
Żeby wyciąć pierwsze elemementy które są zderetminowane pzrez 
pozostałe (np. libm.so.6(GLIBC_2.0) determininuje już 
libm.so.6) trzebaby tylko zmodyfikować skrypty do find_requires.

Jeszcze większe rezerwy tkwia w linker linterze któtóry wicinałby z 
nagółków elf binarek te biblioteki które są używane pośrednio. To niemniej 
jest pieśń przyszłości.

Po co to ?
Ano po to że skracajać listę powiazań miedzuy pakietami bebez utraty jej 
jednioznacznosci zyskujemy na pedkosci obsługi bazy pakietów. Mówiąc 
inaczej pedkość jej obsługi nie dbędzie dalej wzrastała w raz z 
zwiekszaniem sie średniej ilości pakeitów zainstalowanych w danym 
systemie i/lub w systemach w których ilosć ta nie bedzie rosła operacje na 
bazie pakeitów ulegna przyśpieszeniu.

> 3. Sprawa rozwiazywania lub nie(!) nazw pakietow w ramach BR pozostaje
>    otwarta
>    [pamietam ze sie kloczek ostatnio czepial braku nazw, wiec wyglada to
>     na zmiane stanowiska]

Ano .. to jest sprawa otwarta i wymaga poprostu przenalizowania jeszcze.
Wymaga to przjrzeni się jeszcze raz czemu ma to słuzyć i czy spełnia 
założenia jakich spełnienie jest tu potrzebne .. wystarczajaco dobrze.

> 4. Zmniejszenie liczby wpisow w BR powoduje szybsze budowanie pakietu przy
>    duzej bazie
>    [do mnie ten argument nie trafia - uwazam to za (obecnie) nieistotne]

Drobne nieporozumienie/niezrozumienie chyba. Wpływ raczje bedzie cięzko 
zaobserwować :)
Newer majnd .. :)

> 5. [argument Radka, z ktorym sie zgadzam, a ktory kloczek uwaza za nieistotny]
>    Zmniejszenie ilosci *pakietow* wymaganych w BR uprosci proces budowania
>    - mozna hurtem przebudowywac pakiety wzajemnie od siebie zalezne.

Tu zdanie zmieniłem w trakcie naszej rozmowy :)
To co podsumowałeś z tego co twierdzi Radek jest zawarte w tym co 
napisałęm na pocżątku tego komentarza. Jęzlei lista będzie juz 
jednoznaczna to jej wydłuzanie nie będzie potzrebne .. bo juz bedzie 
optymalnie opisywać build odowisku. Tu jak na razie widże że wszyscy 
trzebj myślimy podobnie :)

Jedyna niezręcznsć jak narazie dla mnei to formułowanei ogólnych wymogów. 
Z jednej strerony powinny dużo rególować. Z drgiej steony w sporej ilości 
pakietów w tym perlowych możnabyt dopuszczć wyjątki (jednak) od tychże
regół. Nie powinno tutaj dochodzić do łamania wymogów o ile regóły jednak 
bendą sformułowane ogólnie. Myślę że stosowanie się do trzech punktów 
jakei napisałem na początku tego listu formułująć jeszcze raz/nieco
inaczej to o czym rozmawialiśmy telefnicznie powinno być do przyjęcia :)

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*