Andrzej Krzysztofowicz <[EMAIL PROTECTED]> [02-06-2004 13:25]: [...] > Ale ZTCP, w naszej dyskusji pojawil sie jeszcze jeden problem: > jesli tego obsoletes nie bedzie, a w zasobach mamy perl-modules=X z > Provides: perl-foobar=y oraz perl-foobar=y-1, to proba zainstalowania > perl-foobar przy _niezainstalowanym_ perl-modules moze doprowadzic do > zainstalowania obu. A twierdziles, ze w takiej sytuacji ze wzgledu na > kolejnosc katalogow w sciezce poszukiwania modulow uzywany by byl > perl-foobar=y-1. I moze to doprowadzic do wadliwego dzialania samego perla.
> IMO powazniejszy problem. Zwlaszcza, ze twierdziles iz istnieje taki pakiet > w CPAN. ,,Wadliwe działanie samego perla'' to za dużo powiedziane, po prostu użyty zostanie moduł w starszej wersji; prawdopodobnie mało znaczący... Póki co IMO straty spowodowane użyciem Obsoletes znacznie przewyższają korzyści; poczekajmy na lepsze rozwiązanie... Przy okazji: czy dałoby się zastosować te RPM-owe ,,kolory'' do perla i spółki? I kolorować np. po %perl_vendorarch? Chodzi mi o coś takiego: jeśli dany pakiet ma zdefiniowany perlowy kolor o jakiejś wartości, to inne pakiety, które mają kolor o innej wartości są dla niego niewidoczne z punktu widzenia zależności RPM-a. > BTW: puszka Pandory juz zostala otwarta... perl z Obsoletes juz poszedl do > ready/ (mozna go wyciac, ale i tak trzeba bedzie podbic rel. i > przebudowac). Jestem za tym rozwiązaniem. -- Radosław Zieliński <[EMAIL PROTECTED]> [ GPG key: http://radek.karnet.pl/ ]
pgpuIQpO2vtlM.pgp
Description: PGP signature
