perl 5.8.0

[Radoslaw Zielinski]

Witam,

Moja dłubanina na branchu PERL_5_8_0 doszła już do stabilnego etapu.
Zmiany:

1. Katalogi dla modułów.

   Mamy trzy grupy katalogów:
   a) te, do których wrzucane są moduły z pakietów, budowanych
      z perl.spec: perl_privlib i perl_archlib
   b) te, do których moduły wrzucają inne pakiety: perl_vendorlib
      i perl_vendorarch
   c) te, do których wrzucane są moduły instalowane ,,z ręki'':
      perl_sitearch i perl_sitelib.

   Definicje:

     $ perl -V:install{{priv,arch}lib,{vendor,site}{lib,arch}}
     installprivlib='/usr/share/perl5/5.8.0';
     installarchlib='/usr/lib/perl5/5.8.0/athlon-pld-linux-thread-multi';
     installvendorlib='/usr/share/perl5/pld_perl/';
     installvendorarch='/usr/lib/perl5/pld_perl/5.8.0/athlon-pld-linux-thread-multi';
     installsitelib='/usr/local/share/perl5/';
     installsitearch='/usr/local/lib/perl5/5.8.0/athlon-pld-linux-thread-multi';

   Nie wiem, czy "pld_perl" to nie przegięcie pały...  MDK na przykład
   stosuje domyślne "vendor_perl".


2. Katalogi dla stron podręcznika systemowego.

   Sekcja pierwsza zostaje normalnie, sekcja trzecia przenosi się do
   /usr/share/man/man3p.  Zdefiniowałem odpowiednie makro w macros.perl
   (także na RA-branch, żeby można było od biedy budować moduły ze
   speców w środowisku Ra -- nie na builderach oczywiście).  man.spec
   już poprawiłem i podniosłem release.

   Rozszerzenia takie, jak obecnie na HEAD -- .1/.3perl dla modułów
   ze standardowej dystrybucji perla i .1p/.3pm dla doinstalowywanych.


3. Reorganizacja pakietów.

   Zupełna.  Zrobiłem to od początku.

   Wydzieliłem pakiet perl-base; powinien udostępniać bardzo podstawową
   instalację perla dla różnych programideł.  To, co jest tam teraz
   wrzucone trzeba jeszcze obciąć.

   Pakiet perl-modules zawiera resztę modułów ze standardowej
   dystrybucji.

   Oprócz tych związanych z kompilowaniem rzeczy okołoperlowych, to
   wyleciało do perl-devel.

   Oprócz tego osobne pakiety dla dokumentacji i różnego rodzaju
   narzędzi, oraz microperl (nie testowałem, co to warte).

   Pakiet perl zawiera w zasadzie tylko zależności.  Chwilowo jest tam
   także perldoc i jeszcze jakieś popierdółki, ale to też jest do
   wyrzucenia.

   Głównym założeniem, które mi przyświecało, było umożliwienie (w
   przyszłości) instalowania kilku wersji perla -- dwa różne perl-base,
   perl-modules czy perl-devel nie konfliktują ze sobą (poza symlinkiem
   /usr/bin/perl).  Temu też służy wprowadzenie (do użytku, bo
   zdefiniowane jest od dawna) makra __perl -- żeby można było wybrać,
   dla którego perla ma być budowany dany pakiet.


4. db.

   Wersja DB_File, dystrybuowana z perlem nie nadąża oczywiście za
   rozwojem db -- nie kompiluje się, więc trzebaby łatać...  A pakiety
   budowane z perl.spec mają być z założenia łatane / zmieniane jak
   najmniej.

   Rozwiązanie: wywaliłem DB_File zupełnie.  Jest w osobnym pakiecie.


5. gdbm.

   Też wywaliłem, ale trzeba jednak będzie je włączyć -- nie są już
   rozprowadzane w postaci osobnych modułów.


6. Wątki, LFS.

   Nie stwierdziłem powodu, żeby nie włączać domyślnie.


Pozostało:
- podbić release RPM-a ze względu na nowy perl.prov,
- polecieć z półautomatu wszystkie dotykające perla spece: zamiana
  perl_site{lib,arch} na perl_vendor{lib,arch}, %{_mandir}/man3 na
  %{perl_man3dir} i dodanie argumentu INSTALLDIRS=vendor do każdego
  wywołania "perl Makefile.PL" lub hacka z "perl -MExtUtils::...",
- coś jeszcze, ale zapomniałem.


Komentarze, wątpliwości, joby?  Jeśli nie będzie, to na weekend planuję
,,The Great Merge of Borg''.

-- 
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/15a7ea83/attachment.bin