SPECS: perl-Storable.spec (REMOVED), perl-Time-HiRes.spec (REMOVED...

[Radoslaw Zielinski]

Andrzej Krzysztofowicz <ankry w green.mif.pg.gda.pl> [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 <radek w karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]
-------------- następna część ---------
Załącznik, który nie był tekstem został usunięty...
Name: nie znany
Type: application/pgp-signature
Size: 189 bytes
Desc: nie znany
Url : /mailman/pipermail/pld-devel-pl/attachments/20040626/f60bd7ae/attachment.bin