Ac: perl

[Andrzej Krzysztofowicz]

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

- nie ma potrzeby rozczlonkowywania perla, i wycinania z niego podpakietow w
  wyniku pojawienia sie nowej wersji modulu. Mozna to zrobic, ale nie jest
  to konieczne.
- Czasami moze byc potrzeba zachowania starego modulu nawet po
  zainstalowaniu nowej wersji. Potrzeba moze wynikac np. z zaleznosci.

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

Zeby nie bylo nadmiarowych wymagan ?
Jak sie upierasz, ze maja byc nadmiarowe, bo beda bardziej czytelne, to
mozesz zmienic.

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

Przy hierarchii vendor nie powinno byc problemu.

> Ma to sens żeby wszytko podmieniać ?

Zalezy od okolicznosci. Na tak ogolne pytanie nie ma rownie ogolnej, a
krotkiej odpowiedzi.

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry w mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Gdansk University of Technology