SPECS: python.spec (HEAD) [mmazur]

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Śro, 16 Paź 2002, 23:42:44 CEST


On 16 Oct 2002, Arkadiusz Miskiewicz wrote:

> Mariusz Mazur <mmazur w kernel.pl> writes:
> 
> > On Wednesday 16 October 2002 20:52, wrobell wrote:
> > > Jak już tak zaczynasz rzeźbić, to przygotuj także
> > > ładnego patch-a, który wytnie z dokumentacji Pythona
> > > odwołania do gdbm.
> > >
> > > IMHO, wywalanie lub wrzucanie do supported
> > > wsparcia dla gdbm w Perlu/Pythonie jest bez sensu.
> > 
> > Czemu? Jeśli ktoś będzie chciał to będzie używał (-with gdbm)... standardowo 
> > wspierane to nie będzie. 
> Rozumiem przerabianie aplikacji tak, żeby wszystkie używały db zamiast gdbm
> - to jest w porządku - ale wywalanie wsparcia do gdbma w językach takich jak
> python czy perl lub wywalanie pakietu gdbm z dystrybucji jest chore bo uniemożliwia
> jaki kolwiek dostęp do baz gdbm wygenerowanych przez inne aplikacje. Uniemożliwia
> także konwersję z gdbm->cokolwiek innego.
> 
> Podwowując jestem za wyrógowywaniem użycia gdbma we wszystkich aplikacjach 
> _za wyjątkiem_ aplikacji developerskich.

Arek rozumiem to ale niemniej zauwąż, że de fact w tej chwili 
wykorzystanie gdbm w tym co mamy czy w zasobach innych dystrybucji (o ile 
ktoś chciałby mna zywca pzrechodzić z czegoś na PLD) jest poprstu 
szczątkowe. Ergo: ewentualność konwersji bazy z formatu gdbm do db będzie 
nawet dużo mniej niż sporadyczna .. i o ile "sporadyczny" poziom używania 
gdbm będziemy jakoś obsługiwać to to jzu wystarczy aż za nadto :)

> > Inna sprawa, że żeby zachować "czystość" builderów 
> > kloczek pewnie będzie musiał przy każdym budowaniu czegoś zależnego od gdbm'a 
> > tego gdbm'a instalować, a później odinstalowywać, ale to już nie mój problem 
> > (chyba, że będzie trzeba zmuszać wszystkie programy do ignorowania obecności 
> > gdbma... wtedy to już będzie między innymi mój problem :)
> To jest taka metoda dla leniwych jaką ostatnio się uprawia z np. libbind,
> zamiast poprawić perla to się wywala libbind-devel. W każdym razie to już
> inna bajka.

Z perlem zgoda. Z pozostałymi już mniej. nss_lwres wymagałoby raczje
podzielenia bind-evel i bind-libs bo samo liblwres w sasadzie po za 
nss_lwres nie jest juz chyba nigdzie indziej używane (?).

Druga sprawa że w tej chwili wspieranie innego resolwetra innego niż ten
obecny w glibc zaczyna być już coraz bardziej anachronizmem (jest on w
libc solka 9, a pełne glibc jest w AIXie).

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*



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