perl

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Śro, 14 Maj 2003, 23:38:21 CEST


On Wed, 14 May 2003, Radoslaw Zielinski wrote:

> Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> [14-05-2003 15:38]:
> > W nowym perlu wydzielono perl-base.
> > Już to kiedyś było i wniosek z tych wszystkich prób był raczej taki żeby 
> > to co się miałoby chęć wpakować pod perl-base powinno wlecieć poprostu
> > do perl a ewentualne dodatki do perl-<foo>.
> 
> Nic mi o tym nie wiadomo.
> 
> > Inaczje .. pytanie: co tym razem (znowu) spowodowało że perl nie może się 
> > nazywać poprostu perl a cokolwiek co po perla najbardziej podstawowego
> > wykracza nazywa się perlem ?
> 
> IIRC pisałem już o tym: żeby wszystko ładnie grało.
> 
> 
> Cele (kolejność przypadkowa):
> 
> 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.

> 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.

> W takim układzie, pomiędzy różnymi wersjami perla, powyższe pakiety
> konfliktują ze sobą w trzech punktach: dowiązania symboliczne
> /usr/bin/perl (perl-base) i libperl.so (perl-devel), oraz dokumentacja.
>
> Pakiet perl zawiera: zależności od perl-{base,modules} i perldoc, co
> pozwala spełnić cel pierwszy, oraz katalogi perl_vendor*.  Może być
> zainstalowany tylko jeden na raz (chciałem to zaznaczyć przez dodanie
> Conflicts: perl; niestety, nie działa to tak, jak myślałem).

Nie prowokuj bałaganu. Jeżeli tylko po to wydzieliłeś perl-base to jest 
to raczje do cofnięcia. Jeżeli ktoś chce sobie instalwoać dodatkowego 
perla to nie powinno mieć to wpływu na żaden juz istniejacy zasób perla.
Taką taktykę stosuje się od BSD do Solarisa po wiele innych systemów.

Wiem że chciałbyś mieć przez to lepsze/prostrze możliwości migracji z 
wersji na wersję ale myślenie o devel konfiguracji to nie to samo co
myślenie o produkcji. Lepiej nie łaczyć tu tych dosć sprzecznych ze soba 
celów (uwierz mi). Poziom komplikacji jaki wprowadzisz przy tym zagmatwa 
wiele rzeczy które dotąd były prostymi i mogły nimi dalej zostać.

> Do tego pomniejsze pakiety z mniej znaczącym softem / dokumentacją; jak
> jest, każdy widzi.
> 
> Z tego wszystkiego wynika rugowanie przeze mnie zależności od pakietu
> perl i przystosowywanie czego się da do używania makra %__perl.  Robię
> to już od dłuższego czasu, więc wątpliwości są jakby nieco nie w porę...

Szkoda że nie skonsultowałeś tego .. choćby w opisie celów.

[..]
> > 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.

Spróbuj naprawdę odwrócić nieco logikę tych posunieć i przedewszystkim
myśleć o yużywaniu a nie developmencie. Niech perl poprostu będzie w
pakiecie perl. I jeszcze raz: nie prowokuj zamieszania związenego z
potencjalnie trzymaniem kilku perli na raz w systemie produkcyjnym. Prawie
pewne jest to że przy rozmiarach zasobów perlowych nie da sie tu utrzymać
porządku .. ergo: będzie to tylko niepotrzebnie prowokować do bałaganu.
Dużo proście jest poprostu wykonać czyste przejscie z jednego perla na
drugi w raz całymi przyległościami (mówie o tym z punktu widzenai osóby
używajacej gotowe pakeity a nie zajmujacej się rozwijaniem rtychże).

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 ..

Jeszcze raz: jeżlie wydzielenie gołego perla i biblioteki miałby być tym 
czymś co miałoby służyć tylko upraszaniu migracji z wersji na wersje a 
wiekszej populacji zastosowań i tak trzebaby użyeać perl + perl-base to 
takiw włąsnie podział mówić będzie ze funkjonalnie nie ma to głębszego 
sensu i że próbujesz przyporządkować podział zasobów nie możliwie prostemu 
uzywaniu tylko zupełnie czemus innemu co mało kogo w sumie będzie 
interesować.

Prosze tylko nie odpowiadaj na list od razu. Spróbuj się głębiej nad tym
zastanowić i odpowiodzieć najlepiej conajmniej jutro.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*



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