alsa-driver nie buduje się

[Tomasz Kłoczko]

On Mon, 19 May 2003, Paweł Gołaszewski wrote:

> On Mon, 19 May 2003, Tomasz Kłoczko wrote:
> > > > > > > > To tylko u mnie, czy to jest known problem?
> > > > > > > U mnie identycznie. (Ra z dodatkami)
> > > > > > ALSA i tak wpadnie w postaci patcha do kernela.
> > > > > Po co? Żeby mieć starszą alsę?
> > > > Po to zewbyś pytał się po raz kolejny.
> > > ... kolejny? raczysz żartować.
> > Pisałem już kilka razy o tym
> 
> Że chcesz mieć starą alsę? nigdy.

Coś Ci się pomyliło :>
Gdzie coś takiego napisałem ? :>

> > i byłby to kolejny traz kiedy bym to powtórzył. Po którce: zajrzyj sobie
> > do updates/security i przykrzyj się do czego to prowadzi (ile pakietów
> > musiało tam wpaść tylk odlatego że zasoby kernelowe nie mamy skupione w
> > jednym pakiecie źródłowym).
> 
> Jakoś ilość pakietów perlowych ci nie przeszkadza i nie masz ochoty tego 
> "integrować"...

Perl nie zmienai się częsciej niż raz na rok.
Tymczasem zapewniam Ci że do kernela mówgłbyś każdego tygodnai zebrać taka 
ilosć poparwek żeby meić doklądnei tyle rel pakietu ile tygodni w roku. 
Każda taka zmian bezie pociagać za sobą konieczność przebudowania tony 
innych towarzyszących zasobów.

> > Takie rzdrobienie spowodowało że z powodu jednego patcha na kernel
> > trzeba było poświęcić znacznie więcej sił i czasu na konserwacje tego.
> 
> ... jasne - a konserwacja takiego jednego patcha-krowy będzie łatwiejsza? 
> Nie żartuj.

Tak bedzie łatwiejsz. W przeciwieństwi do Ciebie zaczałem to już
sprawdzać. W przeciweiństwiw do Ciebie pamietam dokłądnei z czym dodatkowo 
wiąże się przebudowanie kernela.

[..]
> Nie - to ty miewasz najbardziej _idiotyczne_ i _niedorzeczne_ pomysły 
> właśnie w poniedziałki. Nie wiem, chyba nuda w weekend tak działa na 
> ciebie.

Dopóty dopóki nie wykarzesz na żywym przykładzie że masz rację tego typu 
zdania sa tylko pustą próbą oburzania się na stan rzeczywistości.
Jeszcze raz napiszę, że potencjalnie wiele osób używających kernela 
neidustryucyu\yjnego potzrebuje nawet popraweinia konkretnych błędów i/lub 
dodatkowych cech które nei sa obecne w tymze dystrybucyjnym kernelu bo:

- już samo zajrzenie do tegoż dystrybucyjnego kernela ze wzgledu na 
  stopień skompilowania pakietu mozę przyprawić o drgawki (to co 
  praktykuje Wojek na branchu to juz state of art w tej kwesji .. zero 
  myśłenia żeby to było mozliwei proste ale za to tona myślenia jak to 
  dodatkowo skompilować choćby poprzez utrzymywanie stada bcondów),

- komuś sie nie chce i tak zintegrować zmiany po mimo że jest to w zasiegu 
  jego możliwości wykonawsczych. Wiecje .. nei ma nawet siły (?) zgłosić 
  że poprawka X warta byłaby wrzucenai do kernela.

W świetle powyższego wysoka koniecznosć stosowanai neidustrybucyjnego 
kernela i sporych nacisków żeby przystosowywać to do tego żeby ktoś mógł 
nie uzywać tegoż w pewncyh częsciach jest czystej wody
*CHOWANIEM GŁOWY W PIASEK* wobec rzeczywistych niedoróbek w konkretnych 
zasobach.

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*