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