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

[Arkadiusz Miskiewicz]

> > 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 :/

-- 
Arkadiusz Miśkiewicz    CS at FoE, Wroclaw University of Technology
arekm w sse.pl   AM2-6BONE, 1024/3DB19BBD, arekm(at)ircnet, PLD/Linux