Zależności w Perlu (było: SPECS: perl-Video-DVDRip.spec (HEAD) [ankry])

[Radoslaw Zielinski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

( Wiem, że początek wielu z Was nie interesuje, ale pod koniec jest
  konkretne pytanie, dotyczące polityki PLD w zakresie modułów Perla
  (nie tylko pakietów perl-*). )


[[ Andrzej Krzysztofowicz <ankry w green.mif.pg.gda.pl> (cytując Kloczka) ]]:
>> Tu mie się wydaje że to jest błą jednak źle tutaj poprawiany.
>> Wystarczy zajrzęć o plików z /usr/lib/perl5/site_perl/Video/DVDRip/GUI/Project
[...]

Tomku, swoim mailem podsunałeś mi pomysł na prawidłowe rozwiązanie
perl.prov, nad czym zastanawiałem się od kilku dni i właśnie miałem
dać sobie spokój.  :-))  Dlaczego moja wredna morda się uśmiecha?
Pozwolę sobie na dłuższe wyjaśnienie...

W Perlu aktualną domyślną przestrzeń nazw definiuje się poleceniem
`package nazwa::przestrzeni::nazw;'.  Wszystko, co następuje później (do
następnego `package' lub końca bloku/pliku)) i nie jest ściśle określone,
przynależy właśnie do tej przestrzeni.

Domyślnie, domyślną jest "main::".

Polecenie `package' nie musi wystąpić, żeby coś zostało przypisane do
innej przestrzeni niż domyślna; taka składnia jest legalna (tak wygląda
,,ścisłe określanie'' / kwalifikowanie):

    sub Foo::Bar::funkcja {}
    $Foo::Bar::zmienna

Żeby dołożyć problemów z parsowaniem, można także nadpisywać już
istniejące obiekty.  Stosuje się to głównie przy dziedziczeniu; np
w Apache::DBI (dziedziczy po DBI); bardziej obrazowe przykłady:

    use CGI 'header';  # eksport funkcji header() z modułu CGI
    sub CGI::header {} # nadpisanie CGI::header

     $ perl -MCGI=header -e '$_=header; chomp; print'                
    Content-Type: text/html; charset=ISO-8859-1
     $ perl -MCGI=header -le 'sub CGI::header {"foo"}; print header'
    foo

Aktualny parser szuka polecenia `package', znajdującego się na początku
linii (problem, gdy ktoś ma fantazję ujmować całą definicję pakietu w
nawiasy klamrowe: "{ package foo;\n") i szuka wersji.  Nie sprawdza się
to choćby w przypadku omawianego perl-Video-DVDRip -- w Provides wpada
choćby perl(DB) (nie widzę sensu w odpowiednim kawałku kodu, szczerze
powiedziawszy, ale patrzałem tylko przez chwilę).

> W wielu miejscach sciezka do modulu nie pokrywa sie z wewnetrzna nazwa
> modulu. Ba, w paru przypadkach kilka modulow (o roznych nazwach
> wewnetrznych) jest umieszczonych w *jednym* pliku...

> Moze tak powinno byc ?

Tak może być; powinność ma tu niewiele do rzeczy.  Przy czym rzeczywiste
moduły Perla, te z CPANu i instalowane w /usr/lib/perl*, moim prywatnym
zdaniem powinny udostępniać przestrzeń nazw pasującą do ścieżki do pliku
- -- w tym pliku.  Plus ewentualne podklasy.

W praktyce, w pliku może być cokolwiek.  Przykład:

     $ cat Foo.pm
    package Foo;
    print "Foo\n";
    1;
     $ perl -MFoo -e ''
    Foo
     $ cat Bar.pm 
    package Fnord;
    print "Fnord, znajdujący się w Bar.pm\n";
    1;
     $ perl -MBar -e ''
    Fnord, znajdujący się w Bar.pm

Jednak nie można wykonać `(use|require) bareword', gdzie "bareword" nie
przekłada się na nazwę pliku; nawet, jeśli perl wie już o tym pliku:

     $ perl -MBar -MFnord -e ''
    Fnord, znajdujący się w Bar.pm
    Can't locate Fnord.pm in @INC [...]

W przypadku perl-Video-DVDRip, do Provides powinno wpadać tylko
to, co jest wyświetlane przez polecenie (po wejściu do rozpakowanego
archiwum):

$ find lib -name \*.pm|perl -pe 's,^lib/|\.pm$,,g;s,/,::,g;s,^,perl(,;s,$,),'

plus odpowiednie numery wersji.



Rozwiązanie: nie należy szukać po `package', (chyba, że numerów wersji).
Wystarczy rozpoznawanie listy plików.  Wylecą wtedy zbędne informacje
o perl(klasa::podklasa::foo), gdzie to coś jest zdefiniowane w pliku
klasa/podklasa.pm.  Zaimplementuję to... na dniach.



Tu pojawia się jeszcze jeden problem, ale już mniejszego kalibru i
związany raczej z polityką w dystrybucji (Panowie, postarajcie się to
tym razem ustalić wyczerpująco i do końca), a mianowicie:

  _Czy w PLD moduły Perla mogą być instalowane poza /usr/lib/perl*?_

Dlaczego tak?  Bo niekiedy są to biblioteki prywatne jakichś aplikacji,
zapisane w formie *.pm (i ewentualnie opakowane Makefile.PL) dla
czytelności.  Przykład: RT, <http://www.bestpractical.com/rt/>; to
bardzo smacznie wyglądający BTS, wdrażany obecnie przez developerów Perla
(niedługo wrzucę speca).

Dlaczego nie?  Bo im też wypadałoby oznaczyć Provides/Requires,
a bez sensu jest udostępnianie informacji o wirtualnej właściwości
perl(foo::bar), gdy normalna aplikacja nie ma możliwości znalezienia
tego foo::bar.  No i implementacja perl.prov się komplikuje (ale to
akurat jest do rozwiązania).


Ja jestem za ,,nie'': jest prostrze, a mniej kombinowania, to mniej
problemów.

> A moze rpm-perlprov z DEVEL obsluguja to juz inaczej ?

To prawie ten sam skrypt.


ps.  Czy kombinowanie z Epoch w perl.req z DEVEL (po zapatchowaniu linie
255-262) to wymysł (c) PLD, czy można pominąć?

- -- 
Radosław Zieliński <radek w karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9TuWgvesRuUOywuARAisIAKDavBRJdtWVYPaJvVBxY9ROjbPyCgCgtQVI
Q0kvvZna3p6N0EpWBIlAkck=
=iIl7
-----END PGP SIGNATURE-----