Ac: perl

[Radoslaw Zielinski]

[  Ech.  Zabierasz mi cenny czas w imię niczego.  ]

Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> [27-05-2003 06:35]:
> On Mon, 26 May 2003, Radoslaw Zielinski wrote:
>> Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> [26-05-2003 20:49]:
>>> On Mon, 26 May 2003, Radoslaw Zielinski wrote:
>> [...]
>>> Po mimo że napisałeś:
>> [...]
>>> Nadal nie mogę skumać dlaczego to nie może być dołączone to do perl-base
>>> (tworząc perl) albo do perl-modules.
>> [...]
>> Oj, widać, że z Ciebie USENETowy weteran... ;->  Widzę, że stosujesz
>> algorytm ,,wybrać losowy fragment wypowiedzi oponenta, przepisać go
>> i powtórzyć swoją kwestię.  Jeśli nie zadziała, czynność powtórzyć.''
> Tyle tylko, że ten losowy fragment to jedyny fragment traktujacy o tym o
> czym mowam (przyjrzyj się sam swojemu tekstowi).

W <20030521214215.GA3078 w bongo.whisky.rz>, na który nie odpowiedziałeś
wogóle, napisałem:

  > Radek jaki sens jest rbić taki podiał ?
  > Dlaczego nie można poproastu obecne perl-base -> perl, a gołą struktóre   
  > katalogów dołączyć do perl-modules ?
  > Tym samym zniknałby jeden pakiet.

  Tomek, przecież pisałem już o tym.  Skoro zmniejszenie liczby
  konfliktów, przeszkadzających w posiadaniu dwóch wersji perla Cię nie
  interesuje, zostają jeszcze dwa cele, którym to służy:

  1. Chcę perla -- robię "poldek -i perl".  Mam perla.  Nie interesuje
     mnie, jak jest poskładany -- nie muszę tego wiedzieć.

  2. Chcę aplikację, która z perla korzysta -- robię "poldek -i aplikacja".
     Mam aplikację z minimum pakietów, potrzebnych jej do działania.

To właściwie jest jeden cel.  Nie widzę możliwości spełnienia go bez
perl-base.

Wystarczy?

> Radek jeszcze raz: po co w perl *dodatkowa* chierarhia katalogów i to
> jeszcze dodatkowo analogiczna do już udostępnianej przez perla (normalnie
> hierarhi vendor nie ma) która tak samo jak reszta zależna jest od vendor i
> wersji perl ?

Dla oddzielenia modułów, które przychodzą z bazową dystrybucją perla
od ich nowszych wersji, w celu umożliwienia zainstalowania ich z paczek.
Dyskutowałem już o tym kiedyś z Tobą.

[...]
> Dodatkowo z racji istniejącyh na HEAD modyfikacji zaczyna to stopować
> prace nad Ac.

W jaki sposób?  O których modyfikacjach piszesz?  Możesz wykazać, w jaki
sposób modyfikacje, o których myślisz, stopują cokolwiek (pomijając to,
że Ci się nie podobają / nie rozumiesz ich).

>> Nie mam teraz czasu powtarzać się na ten temat; muszę skończyć projekt.
>> Najprościej byłoby, gdybyś mi -- przynajmniej na razie -- uwierzył na
>> słowo, że jest dobrze.
> Czyli co ? do conajmniej czwartku wszystko ma stać ?

Dlaczegóżby miało stać?  Doprowadź do stanu używalności środowisko
budowania i puść, jak jest.

> To ma być żart czy dowcip ?

Grzeczniej.

Nie, to nie żart.  Nie, to nie dowcip.

> W tej sytuacji rozwiąznia są dwa bo to musi być jakoś wyjaśnione. W
> świetle dotychczasowych doswiadczeń mozna brać pod uwagę dwa rozwiazania:  
> albo przebuduję się perla bez hierahi vendor i ze zmiana perl-base-> perl
> albo na razie w bootstrap nie będzie perla 5.8 i wtwedy wycofuję do
> wyjasnienia część zmian z HEAD związanych z perlem.

Rozpieprzysz w ten sposób dużą część zasobów.

[1]

> Mniej inwazyjny jest drugi wariant. I tą drogą na razie pójdę żebyś 
> miał czas wyjasnić o co tu chodzi. Jeżeli w miedzyczasie ani Ty ani
> nikt inny nie będzie w stanie wyjaśnić powodów dublowania hierarhii
> katalogów to znaczyć bedzie że nei ma w sumie powodów tego posuniecia i 
> że można zredukować dodatkową hierarhię vendor.

Ubawiłeś mnie.

Zanim wejdziesz mi w kompetencje, proponuję ćwiczenie.  Wiele modułów,
rozprowadzanych w tarbalu z perlem, możnaby zastąpić ich nowszymi
wersjami bez poważniejszych / łatwych do wykazania implikacji;
przykładem choćby Digest::MD5.  Czy potrafisz zrobić to samo z
ExtUtils::MakeMaker (i stwierdzić z czystym sumieniem, że wiesz, co
robisz)?  Jeśli nie (a wiem, że nie), czy jesteś w stanie umożliwić
instalację z paczki nowszej wersji tego modułu bez hierarchii vendor?


[1]  Mmazur, punkt dla Ciebie.
-- 
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/89916138/attachment.bin