PLD 1.0 beta 1: nowe iso na ftp

[Arkadiusz Miskiewicz]

Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> writes:

> 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
Tu nie do końca się zgadzam. BR powinny jednoznacznie określać
czego dany pakiet potrzebuje by się zbudować i jeśli np. nasz program z
test.spec używa bezpośrednio biblioteki libxyz oraz biblioteki libabc,
a biblioteka libabc używa libxyz do czegoś tam. Do BR w takim
przypadku powinny trafić zarówno libxyz-devel jak i libabc-devel
(mimo, że libabc wymaga libxyz i jest to niejako automatycznie).

Dlaczego tak? Ano dlatego, że BR opisuje nam czego test.spec potrzebuje.
Bez problemu mogę podać sposób na zepsucie budowania pakietu, który
miałby wpisaną jedynie zależność BR od libabc-devel.

Oczywiście gdyby było tak, że test.spec wymaga jedynie libxyz, a z kolei
libxyz wymaga libabc to głupotą jest wpisywanie obu BR do test.spec
- wystarczy libxyz-devel.

> 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ąć:
Ja bym wywalił w cholerę Requires od nazw pakietów. To mi się kojarzy
z przyspieszaniem biegnięcia metodą ,,utnę sobie nogę to będę lżejszy'' :-)
Dodajemy sobie niby ułatwienie, które komplikuje tylko sprawy
(cuda z noauto*) + zwiększa objętość R/P.

> $ 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.
Przykład z libm.so jest ok ale już np. libc.so.6(GLIBC_2.1.3)
!= libc.so.6(GLIBC_2.1) != libc.so.6(GLIBC_2.0).
Nowe wersje niekoniecznie oznaczają kompatybilność wstecz. Nie wiem
czym byś chciał te powyższe zastąpić.

> 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.
Chyba nikt się garbage collectorem w ld nie zajmuje ;\

> kloczek

-- 
Arkadiusz Miśkiewicz   IPv6 ready PLD Linux at http://www.pld.org.pl
misiek(at)pld.org.pl   AM2-6BONE, 1024/3DB19BBD, arekm(at)ircnet, PWr