perl

[Radoslaw Zielinski]

[ Wybacz(cie) opóźnienie; ostatnio niewiele mam czasu na
  PLD i ten stan może się utrzymać do sierpnia/września. ]

Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> [14-05-2003 23:38]:
> On Wed, 14 May 2003, Radoslaw Zielinski wrote:
[...]
>> Cele (kolejność przypadkowa):
[...]
> Szkoda, że nie zasięgnąłeś wczesniej opinii bo ta konstrukcja była już

Pisałem o tym przed przeniesieniem z brancha PERL_5_8_0.  Ze względu na
skalę i konsekwencje zmian, spodziewałem się obiekcji, więc starałem się
napisać o tym dość *wyraźnie*.  Była tu dyskusja.

> ćwiczona i uznana dawno temu za mało przystajacą. Pewne elementu zostały z 
> niej wyssane ale nie wszystkie.

Do czego odnosi się przymiotnik ,,przystający''?
Jakie przesłanki doprowadziły do uznania za ,,mało przystającą''?
Możesz nazwać konkretne elementy, które masz na myśli?

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

Nie widzę tu żadnej nielogiczności.

Z ostatnim zdaniem możnaby dyskutować.  Z punktu widzenia obecnego
podziału, to właśnie pakiet perl zawiera perla minus perl-devel minus
dokumentacja (przez zależności, ale to już nieistotny szczegół
techniczny), a perl-base to tylko jego podstawowy fragment.

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

Potrafisz poprzeć to stwierdzenie argumentacją?

> 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, nie zdaję.  Możesz podać przykładowy scenariusz, obrazujący tę
,,bolesność''?

Po drugie, akurat w przypadku przejścia z 5.6, kwestia zmiany położenia
funkcjonalności jest najmniejszym problemem.

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

Jakiego bałaganu?  
Jakie ,,tylko''?

Trzecie zdanie chyba nie do końca rozumiem.  To, że chcę instalować
więcej, niż jedną wersję perla z paczki musi mieć wpływ na inne paczki,
bo inaczej nie zadziała.

Czwartego zdania w tym kontekście nie rozumiem.  Możesz podkręcić?

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

Tu nie ma żadnej sprzeczności ani podziału na konfigurację devel /
produkcyjną.  System to system, perl ma działać najlepiej, jak to
możliwe.

Komplikacja...  Co jest komplikacją z Twojego punktu widzenia, lub
z punktu widzenia użytkownika?

Owszem, przygotowywanie zasobów skomplikowało się o konieczność bardziej
precyzyjnego podania zależności w BR i pamiętania o konstrukcji
(perl-base < perl-modules < perl-devel).

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

Hmmm...  Że moją grzebaninę na branchu PERL_5_8_0 można było przeoczyć,
to rozumiem.  Wątek przed przeniesieniem na HEAD -- jeszcze też.  Ale
żeby nie zauważyć ilości/skali późniejszych zmian w CVS i nie poszukać
w razie wątpliwości jakichś informacji na ten temat (a pisałem)?

Nie powiem, takie zaufanie mi schlebia. ;-)

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

Dlaczego nieistotne?  Po to są zależności, żeby z nich korzystać.
Żeby nie trzeba było się niczego spodziewać, tylko mieć to jasno
podane.

Zaryzykuję analogię: równie dobrze możnaby się nie spodziewać, że
do używania XFree86 potrzebny jest pakiet XFree86-libs.

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

Poświęcanie jakichkolwiek wartości użytkowych dla ,,developmentu''
nie przeszło mi nawet przez myśl.  Jest on od nich ściśle zależny;
jakkolwiek by ten podział rozumieć.

Obecna sytuacja jest próbą rozszerzenia funkcjonalności o elastyczność,
przy czym nowe możliwości ani z niczym nie konfliktują, ani nawet za
bardzo nie pchają się przed oczy... ;-)

Nie widzę uzasadnienia do przesuwania binarki /usr/bin/perl do pakietu
perl.  To pozbawiałoby sensu istnienia pakietu perl-base, a więc
całkowicie zmieniało obecną -- wdrożoną już we wszystkich krytycznych
aspektach [1] -- koncepcję.

[1] Poza dalszym okrojeniem perl-base, co stanie się przed całkowitym
    release.  Później będzie tam ewentualnie tylko przybywało.

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

#define prowokuj.  To jest tylko możliwość, w dodatku wymagająca użycia
co najmniej --force.  Nie przewiduję obowiązku (a ściślej: przewiduję
jego brak) korzystania z tego przy używaniu jakichkolwiek zasobów
dystrybucyjnych.

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

Jest taka klasa: moduły nie korzystające z XS (większość).  Wpadają do
katalogów %perl_vendorlib.

Owszem, możnaby to rozluźnić jeszcze bardziej: poszczególne wersje perla
bywają binarnie kompatybilne.  Tak jest IIRC z 5.6.0 i 5.6.1, AFAIK też
z 5.8.0 i 5.8.1.

Przypuszczam, że możnaby poeksperymentować z usunięciem ostatniego członu
wersji z SONAME i nazw katalogów, ale to sprawa na później.

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

(Ech.)  Nie, nie tylko migracji.  Możliwość instalacji dwóch wersji to
nie tylko migracja.

Pakiet perl składa się z zależności i nie będzie docelowo nigdzie
wymagany, więc mówienie o "perl + perl-base" to... nie to, o co chodzi.
Raczej "perl-base + perl-modules".  To, żeby w _podstawowych_
zastosowaniach wystarczało samo perl-base, też jest jeszcze sprawą do
dogrania, ale ciężko się za to zabierać przed wyrugowaniem "R/BR: perl".
Drugą ważną sprawą w temacie zależności jest też dodanie wymagania
perl-base w odpowiedniej wersji przez pakiety instalujące moduły
w %perl_archlib (żeby usunąć problemy podczas migracji do kolejnych
wersji); to także ma dla mnie wyższy priorytet.

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