SOURCES: rpm-pld-autodep.patch - remove automated dependency

havner havner w smtp.kamp.pl
Sob, 21 Sie 2004, 00:57:32 CEST


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 21 August 2004 00:40, Jakub Bogusz wrote:
> Zalety R: dla mnie:
> - bardzo dobra integracja z rpm-em i poldkiem
> - wygodne odpytywanie w komplecie z innymi zależnościami
> - działanie offline (bez przechowywania dużych ilości danych) i online
>   (bez ściągania dużych ilości danych)
>   ("dużo" jest względne - dla przechowywania _teraz_ dla mnie 40MB (tyle
>   ma moje Packages) to "dużo", bo nie mam tyle miejsca na / ani /home;
>   dla ściągania - dzienne poldek --up jest akceptowalne, 7MB przy --upa
>   już denerwujące)
>   Po prostu czekanie kilka minut to dla mnie bezsensowna strata czasu,
>   który można wykorzystać choćby na poprawianie innego pakietu.

Hmm, zaraz, linux ZTCW (ale moge sie myslic) ma multitasking, wlaczasz druga 
konsole i pracujesz...

> Potrzebuję funkcjonalności, która podaje listę nazw pakietów
> dostarczających własności (bibliotek i modułów Perla) wymagane przez
> dany pakiet - dystrybucyjny na ftp, jak i zbudowany lokalnie.
> Teraz uzyskuję to odpowiednio przez desc -r i rpm -qpR.

Budujesz lokalnie az tyle libow, ze potem musisz szukac co ktory providuje? 
Imo lekka przesada. A co do bazy PLD to w najgorszym wypadku mozna poza baza 
na iso udostepnic jakis interfece po sieci (baza bylaby trzymana na zdalnym 
serwerze)

> Najbliższe temu byłoby desc -R, ale wymaga poldkowej bazy
> wszystkich pakietów (nie korzysta z rpm-owej bazy pakietów
> zainstalowanych). A dla pakietów zbudowanych lokalnie dodatkowo
> uruchomienia poldka po każdym zbudowaniu pakietu.
> Wolałbym, żeby wymagało nieco mniej danych i czasu (szczególnie w drugim
> przypadku).
>
> Wyszukiwanie po jednej własności w jakimś pliku tekstowym, przez rpm
> --redhatprovides czy search -p jest nieakceptowalnie niewygodne.

Qboosh, ja to wszystko rozumiem, ale nie dostrzegasz wad tego rozwiazania. 
Integracja integracją, ale to WYMUSZA konkretna nazwe paczki dla danego libu 
w zaleznosci, a to jest momentami naprawde upierdliwe. W sumie najwiekszym 
problemem w tym momencie sa xlibs. Napisales jak to zrobic. Gdyby wrzucic 
wszystkie xlibs do noautoreqdep.. Ale nie kombinowac juz potem z dodawanire 
sztucznych R:XFree86, czy jakis innych. Cos takiego to chyba kazdy widzi. 
Przeciez R: libX.so.X zostaje. Tak samo nie dodajesz R: OpenGL tam gdzie jest 
noautoreqdep na libGL.

Requires:       OpenGL
%define         _noautoreqdep   libGL.so.1 libGLU.so.1

Jaki to ma sens? Po co komus info, ze R: OpenGL, jak ma R:libGL? To samo z 
xlibs. Wrzucic wszystkie do noatuoreqdep i koniec, zadnych kobinacji wiecej.

I poprawka tego nadgrywania noautoreq. Tak jak jest teraz jest 
niedopuszczalnie imo.

Zreszta ja _nadal_ nie rozumiem niecheci do poldka. Ludzie pisza tu, ze na 
16mb ramu go odpalaja i idzie. Az tak czesto nie robisz chyba tego, zeby 
musiec miec zapewniona az taka wygode za kazdym razem.


- -- 
Regards       Havner                          http://livecd.pld-linux.org
GG: 2846839                             jid,mail: havner(at)pld-linux.org
          "We live as we dream, alone"   - Joseph Conrad
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBJoHdgvS01FGjsR8RAjyCAKDE9AEkhvy9JVadXHbC+bYwG1MyHQCdED5Y
T9zcTaEjbxZntINVz+Mh9OY=
=gaQi
-----END PGP SIGNATURE-----




Więcej informacji o liście dyskusyjnej pld-devel-pl