perla nie da sie zbudowac ?

[Radoslaw Zielinski]

Andrzej Krzysztofowicz <ankry w green.mif.pg.gda.pl> [22-11-2002 17:05]:
>> plik /usr/lib/perl5/5.6.1/base.pm jest potrzebny do zbudowania
>> perl-Class-Fields, ale nie da sie zbudowac perl-Class-Fields bez pliku
>> base.pm i kolko sie zamyka.

Ups, nie zauważyłem.  Rozwiązanie na chwilę obecną: rpm -i
--nodeps perl-Class-Fields z FTP; to jest pakiet noarch.

>> proponuje, poprostu zlikwidowac pakiet perl-Class-Fields a base.pm
>> wsadzic do perl.spec czyli odkomentowac to co jest zakomentowane obecnie

Problem w tym, że wersja base.pm, dystrybuowana z perlem 5.6.1, jest
dość stara.  Zdecydowałem się na to, co jest obecnie, bo coś kiedyś
wymagało nowszej.

>> lub jakie jest inne rozwiazanie ?

Widzę dwa:

1. Zignorować i czekać na rewolucję przy okazji 5.8.

2. Odkomentować base.pm w perl.spec i zmienić perl-Class-Fields.spec
   tak, żeby wrzucał wszystko do %{perl_sitelib}.

> Przyjrzec sie nowemu perlowi ?

To, co leży na branchu PERL_5_8_0, jest totalnie rozgrzebane.
Zmodyfikowałem jeszcze jakieś trzy patche, ale nie wrzucałem ich jeszcze
do CVS; jak ktoś chce się tym zająć, to podeślę.  Niestety, nie mam
teraz na to czasu (i przez jakieś dwa tygodnie się nie zanosi).

> Wtedy perl-Class-Fields nie bedzie potrzebny... ?

Prędzej czy później, będzie.

Problem w tym, że nowe, stabilne wersja perla wychodzą w odstępach rzędu
roku, a biblioteki i oprogramowanie od perla zależne -- bardzo często.
Te biblioteki (zaliczam do nich to, co zawiera CPAN) mają prawo wymagać
przy budowaniu zarówno obecności pełnej dystrybucji perla, jak i nowych
wersji dostarczanych z nim modułów.

Idealnie, w systemie powinna znajdować się zarówno pełna dystrybucja
perla wraz z dostarczanymi z nią modułami w tych wersjach, które są
dostarczane, jak i ich nowsze wersje. [1]

Istnieje odpowiedni mechanizm; katalogi:

   /usr/lib/perl5/%{version}/   -- na moduły dostarczane z perlem
   /usr/lib/perl5/site_perl/    -- na instalowane przez użytkownika
   /usr/lib/perl5/vendor_perl/  -- na dostarczane w pakietach (np. RPM)

Drugi i trzeci (zwłaszcza trzeci) spokojnie można oczywiście nazwać
inaczej.  Określa się to w trakcie budowania perla; aktualny stan
pokazuje polecenie:

   $ perl -V:privlib -V:sitelib -V:vendorlib


Problem: spakowanie tego porządnie.  Na tym wysiadłem, nie mam pomysłu.
Podział na perl i perl-modules jest w większości sztuczny, z perl-devel
też sprawa nie jest jasna...  Jedyne poprawne rozwiązanie, jakie widzę,
to wrzucenie wszystkiego do jednego pakietu, ale to ze zrozumiałych
względów nie jest akceptowalne.


[1] Tak jest w Debianie.  Ich polityka odnośnie perla to IMO kawał dobrej
    roboty: <http://www.debian.org/doc/packaging-manuals/perl-policy/>.
    Nie wiem niestety, jak to tam wygląda w praktyce.

-- 
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/8c166fad/attachment.bin