perl

Radoslaw Zielinski radek w karnet.pl
Śro, 21 Maj 2003, 23:42:15 CEST


Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> [20-05-2003 11:04]:
> On Tue, 20 May 2003, Radoslaw Zielinski wrote:
[...]
> - to co mniejwiecej [1] było w perl-modules jest w perl-base,

Nie.  W perl-base jest mniej-więcej to, co było w perl (a przynajmniej
to, co powinno tam być; poprawności poprzedniego podziału nigdy nie
weryfikowałem).

[...]
> Mówiac inaczej zamieszanie jednak jest to to pod pewnym wzgledem nawet 
> wieksze niż poprzedni :) bo nie dość że perl nie zawiera parla to w sumie 
> nie zwiera niczego istotnego.

Zawiera zależności.  Według mojego poziomu zrozumienia RPM-a i systemów
na nim opartych, całkiem istotne.

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

> [..]
>>> $ rpm -q --qf "[%{REQUIRENAME}\n]" automake | grep "perl("
>> [...]
>>> To co napisałem w pierwszym liście tego wątku było mni. spowodowane 
>>> właśnie bezposrednimi obserwacjami i przemyśleniami z praktycznego 
>>> używania proponowanego układu w automake.
>> Czy automake aby na pewno jest aby pakietem potrzebnym w typowym
>> systemie?
> Nie. automake jest poprostu takim niejwięcej dość średnim reprezentantem
> pakietów które mają jakieś związki perlem.
> Poprostu jako taki nadaje się dość dobrze żeby próbowac przystawiać to do 
> nowego perla i sprawdzić jak to się bedzie układać.

Moje pytanie nie było przypadkowe.

Wydzielenie ,,minimalnego kawałka perla'', jak perl-base, jest dość
umowne.  IMO powinien zawierać nie tylko to, co jest bezwzględnie
potrzebne do działania, ale także to, co jest najczęściej używane na
typowym, użytkowym systemie -- takie wypośrodkowanie pomiędzy
objętością, a tym, żeby perl-modules nie było wymagane w możliwie dużej
liczbie prostych programów.

> [..]
>>> IMHO już to pierwsze faktyczne wdrożenie odsłania tu spore niedobory 
>>> proponowanego podziału (tak czy inaczej po mimo tego co było pisane móje
>>> osobiste pozytywne podejści do tego znacznie osłabło).
>> Hmmm, ja nigdzie nie pisałem, że to jest skończone.
> Co jeszcze Twoim zdaneim jest ot w takim razie do skończenia ?

# TODO:
# - Think about unicore.  If uf8*.pm, encode.pm, charnames.pm (and
#   probably others) are in the perl-base package, unicore should also
#   be there.  But it's 5MB...
# - profile the perl-base vs. perl-modules separation
# - fix "FIXME"s, review "XXX"s
# - fix perl.prov's handling in rpm -- it should use the __perl macro
# - fix some duplicate files (are there any left?)
# - add the {O,N}DBM_File modules
# - review the perldiag.pod issue
# - consider disabling ithreads by default
# - move the perl_vendorarch directories to perl-base (?)
#
# TODO for perl-dependent packages:
# - change all "R/BR: perl" to one of perl-{base,modules,devel}
# - use the requires_eq(perl-base) for all packages strictly depending
#   on the perl version used for building (files in perl_vendorarch
#   directories; dependency on libperl.so.* often doesn't exist)
#   (should this be done on Ra-branch, too?)

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


Więcej informacji o liście dyskusyjnej pld-devel-pl