[rpm] Rozwiązywanie wirtualnych właściwości na nazwy pakietów

[Jakub Bogusz]

On Wed, Aug 20, 2003 at 04:02:34PM +0200, Arkadiusz Miskiewicz wrote:
> > > Przykłady: perl(base) -> perl-base i perl-Class-Fields,
> > > perl(Filter::Util::Call) -> perl-modules i perl-Filter.
> >
> > Eeeeee... Zaraz. To nie powinno być tak, że jeśli dwa pakiety udostępniają
> > daną funkcjonalność to (a) jednemu się pozajączkowało i kłamie, lub (b)
> > poldek daje do wyboru, że instalujemy albo ten albo ten (tak jest w całej
> > reszcie przypadków). Perl jest jakiś inny?
> Mylisz się. Przykład glibc i uClibc - oba pakiety dostarczały libpthread.so.0
> w różnych lokalizacjach - co teraz?
> 
> Kolejny przykład to valgrind udostępniający moduł libpthread.so.0. W 
> openoffice-libs też swego czasu jakaś taka biblioteka była.
> 
> Efekt - budujesz pakiet używający pthread, który zależy potem od
> glibc, uClibc, valgrind, openoffice-libs zamiast tylko glibc.
> 
> Jestem za wywaleniem generowania zależności od nazw pakietów. Nie jest to 
> rozwiązanie idealne bo poldek i tak się pogubi zasysając np. openoffice-libs 
> zamiast tego co należy :/

Czyli wcale nie rozwiązuje problemu (jedynie przesuwa go z czasu
budowania na czas instalacji).

W przypadku perla będzie tak samo - wybór losowy lub ręczny (w
zależności od choose_equivalents_manually). W tym pierwszym przypadku od
przypadku zależy, czy dodatkowy moduł perla zostanie zainstalowany czy
nie.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/