perl

Jakub Bogusz qboosh w pld.org.pl
Pon, 19 Maj 2003, 00:31:08 CEST


On Wed, May 14, 2003 at 11:38:21PM +0200, Tomasz Kłoczko wrote:
> On Wed, 14 May 2003, Radoslaw Zielinski wrote:
> > Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> [14-05-2003 15:38]:
[...]
> > 1. udostępnienie pełnej (-> takiej, jak z tarballa) instalacji perla,
> > 2. udostępnienie instalacji minimalnej -- używalnej na systemach
> >    z ograniczoną ilością przestrzeni dyskowej lub potrzebujących
> >    jedynie podstawowej funkcjonalności,
> > 3. umożliwienie instalowania dwóch wersji perla.
> >
> > Obecna konstrukcja opiera się na Debianowej i pozwala te cele wypełnić
> > (trzeci z utrudnieniami, związanymi z ograniczeniami rpm-a, ale da się).
> 
> Szkoda, że nie zasięgnąłeś wczesniej opinii bo ta konstrukcja była już
> ćwiczona i uznana dawno temu za mało przystajacą. Pewne elementu zostały z 
> niej wyssane ale nie wszystkie.

Nie? Radek napisał tutaj na temat Perla kilka długich listów, reakcja
była znikoma lub żadna.

> > perl-base zawiera instalację minimalną: /usr/bin/perl -> perl%version,
> > libperl.so.%version, podstawowe moduły i te uznane za często używane
> > (ich lista, zwłaszcza pragm, zostanie jeszcze obcięta przed nadaniem
> > całkowitego release; pliki *.ph też może wylecą).
> > 
> > perl-devel -- oczywiste, moduły i pliki potrzebne do budowania rzeczy
> > okołoperlowych.
> > 
> > perl-modules -- reszta modułów.
> 
> Dobra u nas jest jeszcze na hEAD pakeit perl i to właśnie tworzy ową
> nielogiczność. Pakiet perl nie zawira perla, a zawiera go perl-base.
> Poprostu minimum powinno pozostać w perl a reszta o ile uznasz np. że nie
> mieści się jeszcze w perl-modules powinna wpaść do innego pakietu.
> Może nei zdajesz siobei z tego sprawy ale twego typu przetasowanei bedzie 
> bardzo bolesne z punktu widzenia przejscia z perla 5.6, bo perne 
> funkcjonalności zmieniają kompletnei swoje położenie.

Nie zauważyłem problemów przy uaktualnianiu.
I tak prawie zawsze instalacja obejmowała perl-modules i perl-devel,
częściowo ze względu na nieudane wydzielenie pakietu -devel.

> [..]
> > > Poprostu tworzy to z lekka alogiczny układ ..
> > 
> > O ile "alogiczny" == "taki, w którym nie widzisz logiki"...
> 
> Wybacz ale wątpie żebym tylko ja spodziewał sie że nie nie znajdę perla w
> pakiecie perl :)
> To ze instalacja perla pociagać miałaby za sobą perl-base jest tu 
> nieistotne.

Zależy jak patrzeć na Perla.
Dla piszących jednolinijkowce perl to /usr/bin/perl, a dla perlowych
programistów kompletna instalacja.
Po "poldek -i perl" instaluje się perl - w obu znaczeniach.
I programista nie musi się zastanawiać "gdzie się .* podziała
dokumentacja" (albo moduły) - i to nie jest wydumane, ale zasłyszane :)

Też na początku patrzyłem sceptycznie na nowy podział perla, ale teraz
nie widzę większych wad. A możliwości istnienia kilku wersji nie brałem
nawet pod uwagę.

> Może warto zastanowić się przy kazji czy aby napewno każdy zasób perlowy
> musi wpadać do katalogów zależnych tak ściśle od wersji perla (bo to jest
> głowne utrudnienie migracji z wwersji na wersję a nie to jak nazwy sie
> binarka perla i biblioteka bo w tej chwili przy każddej zmianie wersji
> wymaga to przebudowywanai całosć zasobów perlowych zeby je zrelokować do
> innego drzewka) jak teraz ale to już osobna sprawa i jeżeli już to raczje
> tu uparywałbym rezerw w manewrach w kwesji upraszania migracji z wersji na
> werswję. Spróbuj o tym lepiej pomyśleć czy aby porostu nie jest tu za duży
> rygor który możnaby neico rozluźnić wprowadzajć klasę zasobów niezależnych
> ściśle od wersji perla. Zmian powinna być prosta bo wyssdtarczy że perl 
> będzie przeszukiował dodatkowo ścieżke neizalezną od wersji ..

Moduły czysto perlowe instalują się w katalogu niezależnym od wersji.
A z tymi z częścią binarną raczej nie można inaczej, bo ABI może się
zmieniać z wersji na wersję, w zależności od włączenia lub nie wątków
itp.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/



Więcej informacji o liście dyskusyjnej pld-devel-pl