Ac: perl

[Tomasz Kłoczko]

On Tue, 27 May 2003, Radoslaw Zielinski wrote:
[..]
> 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?

Nie poniweważ powyższe w żaden sposób nie tłumaczy po co miałaby być nowa 
trzymana dodatkowa hierahia vendor w zasobach perla.

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

Po co ? Po co to oddzielać ?
Dlaczego nie może być tak jak do tej pory ?
Jakie względy techniczne a nei estetyczne przemaiwaja za tym że to mozę 
mieć sens ?

> [...]
> > Dodatkowo z racji istniejącyh na HEAD modyfikacji zaczyna to stopować
> > prace nad Ac.
> 
> W jaki sposób?

W taki że glibc.spec stoi wpisane obecnie jawnie
"BuildRequires: perl-base". Pytanie: dlaczego nie poprostu perl ?

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

To może wreszcie choć raz zauwązysz że któryś raz z kolei pytam 
sie po co to jest i spróbujesz odpowidzieć na to pytanie (?)

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

Wywalasz Digest::MD5 i na to miejsce wskakuje moduł rozwijany osobno.
W wczym problem ? Tak jest zrobione w Debianie RH, MDK  i kilku innych.
Czy ludzie z tych dystrybucji popełniaja tu jakis błąd ?
Juz tylko to że przypuszczalnie jeżeli tak miałoby być to byłoby o tym juz 
dość głośno.

> Czy potrafisz zrobić to samo z
> ExtUtils::MakeMaker (i stwierdzić z czystym sumieniem, że wiesz, co
> robisz)?

Potrafisz to zrobić ?
Ma to sens żeby wszytko podmieniać ?
Jeżeli nie to do mometu aż nie będziesz wiedział Ty czy ktoś inny jak to 
podmienić lepiej dać sobei z tynm spokój jeżlei to nic nie zmieni.

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*