jeden wielki kernel.spec vs wiele kernel-*

[Marcin Bohosiewicz]

On Fri, 23 May 2003, Tomasz Kłoczko wrote:

> On Thu, 22 May 2003, Marcin Bohosiewicz wrote:
> 
> > > > 
> > > > P: e100/e1000 z kernela to śmieć, a ja potrzebuję czegoś porządnego,
> > I cieciwa chyba wogole zamierza budowanie tego "okastrowanego" e100 i 
> > e1000 wylaczyc, bo i tak sie do uzytku nie nadaja.
> > 
> > > > T: dlaczego nie używasz kernerla dystrybucyjnego ?
> > > > P: bo e100/e1000 z kernela to dla mnie śmieć, a ja potrzebuję czegoś 
> > > >    porządnego.
> > I jest prosciej. Niech mi ktos wytlumaczy, jak moze byc prostsze
> > dodawanie e100/e1000 do kobyly kernel.spec (i kompilowanie tego po kilka 
> > godzin) od konserwowania 3 malutkich specow kernel-net-e100.spec,
> 
> Znowu jakieś nieporozumienie.
> Marcin Ty używasz kernela dystrybucyjnego czy nie ?
Używam. Gdzie się da (x86) 2.2, gdzie się nie da (ppc) 2.4 od cieciwy.
Teraz będę zmuszony uzyć 2.4 od cieciwy na x86 bo musze miec na jednym 
serwerze iptables i htb sprawne. Po ostatnich poprawkach Qboosha to 2.4
stało się naprawdę stabilne...

Btw, juz nie pamietam, kiedy ostatni raz kompilowalem calego kernela 
ręcznie.... zawsze brałem go z rpm'a. 
Czy to z Ra czy z ftp.kernel.pl/pub/People/cieciwa.

> Powiedź mi jezlei yużywasz to jaki ma sens zawracanie sobie za każdym 
> razem głowy jeszcze jednym pakietem w którym jest dokładnie jeden moduł ?
Ano taki, że ten pakiet żyje własnym zyciem, ma odrębny cykl wersji i juz
nie jeden raz okazalo się, że to że jest osobno mi pomogło.
Miałem sytuację, gdzie najnowsza wersja (to akurat bcm5700) NIE DZIAŁAŁA
z karta którą zastałem w serwerze. Przez to, że bcm5700 jest w osobnym 
specu mogłem szybko zrobić z tym porządek (wziąłem starszą wersję i 
przebudowałem) i zaspokoić potrzebę klienta. A gdyby to było wewnątrz 
kernela... brrr... kilka godzin kompilacji, sztukowania patchy... 
pewnie telefonowania do cieciwy czy dzimiego. Dziękuje. 
Mnie jest wygodniej miec sterowniki dostarzcane ze żrodeł !kernel.org osobno.

> Zapominasz o tym co jest w updates/security.
Nie, nie zapominam. Tak ma byc. Jak sie robi update kernela to i 
przyległości. I to nie tylko kernel-* ale i np iproute2, gdzie stare
z nowymn kernelem poprostu NIE DZIAŁA (no tak, nie każdemu htb potrzebne,
ale jak juz kernel ma wsparcie to i userland miec powinien).
> 
> Przyjmujac to co sugeruejsz należałoby rozwalić kernela na tyle pakretów 
> (źródłowych) ile jest modułów w kernelu bo niby dlaczego e100/e1000 maja 
> być tu wyjątkowe ?
> 
> [..]
> > Rozumujac tok myslenia Tomka do kernel.spec nalezaloby wlaczyc conajmniej:
> > iproute2 (bo htb,cbq itp.), iptables (bo dla kazdej wersji netfiltra
> > musi byc osobno kompilwoany), util-linux (dla mounta), freeswan (bo musi
> > byc kompilowany pod aktualna wersje ipsec.o). Mozna jeszcze wymieniac
> > sporo pakietów, które defacto powinny miec %requires_eq na kernel
> > ale nie maja by mozna bylo uzywac kernela niedystrybucyjnego (np z mosixem).
> 
> Ta .. staliśmy nad przepaścia i zrobiliśmy wielki krok do przodu :>
> Gdzie pisałem coś o narżedziach ?
> Czy któreś z tych narzędzie regularnie przestaje działać po upgrade 
> kernela ?
Tak. Te co wymieniłem. iproute2 zależy dosyć mocno od wersji patchy na
schedulery pakietów (cbq, htb) i przy niezgodności narzędzie "tc" staje
się bezużyteczne. To samo z iptables, które teraz ma @{_ker_ver} w release.
Z freeswanem też jest tak, że część userlandowa musi byc zgodna z tym, co 
jest aktualnie w kernelu (ipsec.o od 1.97 nie zadziała z freeswan 2.0 np.).
I takich rzeczy będzie niestety coraz więcej, bo w miarę rozwoju kernela
do API dochodzą nowe rzeczy, które userland musi umieć obsłużyć.

> 
> > Ad absurdum.
> 
> Sam to stwierdzasz ale to nie jest jednocześnei to co by wynikało z tego 
> że moduły do konkretnego kernela są w konkretnycm katalogu.
Zrozum, że sam katalog to NIE WSZYSTKO.
Moduły _muszą_ być kompilowane z tym samym kernelem, jeśli ma to być
stabilne - pamiętam jak była taka sparwa z którymś 2.4.20 na ppc,
że moduły od wcześniejszych release owszem ładowały się, ale próba ich 
użycia (tam to bylo postawienie sieci) kończyły się ładnym oopsem.
> 
> > Moze dla "spojnosci" zrobisz Tomku pld.spec z ktorego cale PLD sie
> > bedzie generowalo jako podpakiety? A i pamietaj o zlepieniu wszystkich
> > patchy w jeden i wszystkich tarow w jeden. Bo jesli proponujesz to przy
> > okazji pakietów "okolokernelowych" to patrzac na to, ze od wersji
> > kernela bedzie zalezec coraz wiecej pakietow (np niedlugo sie moze
> > okazac ze glibc) perspektywa jest taki pld.spec plus moze kde i gnome i
> > troche drobnych aplikacji (jakies nmapy,poczty itp.).
> 
> Jakiś czas temu powstało pojęcie "twórcza księgowość" to co prezentujesz
> nazwać by wypadało "twórczym rozumieniem".
Specjalnie to chcialem przejaskrawić. Żebyś zrozumiał, ze wrzucanie za 
dużej ilości rzeczy do jednego wora przynosi wiecej szkody i straty czasu 
niz pozytku.

M.
-- 
-| == Marcin Bohosiewicz - MB8042-RIPE - marcus w kernel.pl	== |-
-| == tel. +48 601 485097 - PLD Team   - marcus w pld.org.pl      == |-
-| == http://www.kernel.pl/ -          ftp://ftp.kernel.pl/     == |-
-| == PLUG - Komisja Rewizyjna  -      http://www.linux.org.pl/ == |-