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