Dlaczego kernel-BOOT odpala mi lilo w post?????

[Tomasz Kłoczko]

On Tue, 3 Apr 2001, Michal Moskal wrote:

> On Tue, Apr 03, 2001 at 10:42:55AM +0200, Tomasz Kłoczko wrote:
> > On Tue, 3 Apr 2001, Michal Moskal wrote:
> > 
> > > On Mon, Apr 02, 2001 at 09:35:50PM +0200, Tomasz Kłoczko wrote:
> > > > Pytanie zasadnicze: po co ?
> > > > Instalować teg ow spec katalogu też nie ma sensu bo jak bedziesz chciał
> > > > eksperymentalnie z tego wystartować to bedziesz musiał podejmować spec
> > > > kroki.
> > > > 
> > > > > Właśnie w celu robienia bootkietki (np. mawk skomplikowany ze statycznym
> > > > > libm).
> > > > 
> > > > Kompilowanie czegoś na potrzeby boot dyskietek raczje ma ograniczone
> > > > zastosowanie (do tego ejdnego przypadku). Jakoś nie widze też na razie
> > > > potzreby podejmowania tu dodatkowych kroków.
> > >  
> > > Sorry, albo mi się wydaje, albo sam mówiłeś, że sprawe robienie
> > > bootdisków etc trzeba uporządkować. Widzisz lepszy sposób niż robienie
> > > z tym rpm'ów?
> > 
> > Owszem. Niemniej jeżeli w tej chwili sobie wykonasz make w module z
> > instalatorem to on wyraźnie sprawdza sobie to czy masz zainstalowane
> > kernel-BOOT i wyciąga pliki do zbudowanai całosći z normalnych lokacji.
> > Z jednaj strony w zasadzie prefix do instalcji kernel-BOOT (niemniej i tak
> > do tego musiałaby być przystosowana reszta), a z drugiej analogiczna
> > lokacja kernel-BOOT w porównaniu do pozostałych kerneli w pakietach
> > binarnych ułatwia jego testowanie bez instalatora. W tym sensie IMHO
> > powyyższe przemawia za zostawieniem układu tych plików w takim stanie jak
> > to jest obecnie.
> 
> Czyli jak ktoś chce sie instalatorem bawić, to musi mieć chroot?

Oczywiście nie. Zauważ, że konkretne pakiety typu BOOT będą wymagały tylko
kilku dodatkowych pakietów static (BuildRequires) i to wsyzstko. To można
swobodnie przebudowywać bez chroot. Ale choćby już po ostanich zmianach
mawk jest juz z lekka kopnięty bo wymaga w trakcie budowania libm.a (część
glibc-static), a tej zależności nie ma w BuildRequire i to powinno sie
pojawiać tylko watrunkowo o ile budujesz wersję BOOT.

> No bo jak wyobrażasz sobie na normalnym systemie instalowanie kernel-*BOOT,
> który psuje lilo.conf?

Psuć nie powinien. O ile to robi to jest to bład do poprawienia. Powinien
sie tak samo osadzić jak i klasyczny kernel.

> Tudzież kilka innych pakietów, które będa
> co prawda działać, ale dalece suboptymalnie (statyczne biblioteki).
> Może nie każdy chce robić chroot?

No raczje aż takiej potrzeby nie ma. Wręcz wersja BOOT mogłaby
potencjalnie linkwać sie z diet libc o ile to wyda.

> > > > > To by się dało do powiedzmy /usr/lib/bootdisk I tam by był
> > > > > chroot do bootkietki. Albo jakiś inny katalog. Można by też busybox
> > > > > do rpm'a wrzucic. Co o tym sądzicie?
> > > > 
> > > > Ja bym zaczął od diet libc. Środowisko do eksperymetów z chroot do
> > > > instalatora czy boot dyskietki mozan zrobić w osobnym pakiecie tak jak
> > > > pld-builder.
> > > 
> > > Uhm, pewnie. I śledzić w tym pakiecie zmiany w 10 innych (mawk,
> > > util-linux etc.), nie prościej dodać 10 liniej do kilku innych
> > > speców?
> > 
> > Co IMHO tylko pokazuje, że podpakiety BOOT w tym wypadku są jednak trochę
> > mało sensowne (z kernelem włącznie). Raczej powinno być to zrobione na
> > bcond. Obecne wkładanie także kernel-BOOT jet też nieco mało spójne jeśli
> > chodzi o wrzucanie tego na ftp w drzewko z reszta pakietów.
> > Na dobrą sprawe możnaby to zrobić nieco inaczej. Przy podaniu --with BOOT
> > przy budowaniu mogłyby powstawać pakiety typu kernel-x.x.x-x_BOOT i reszta
> > analogicznie. Nie musiałby być one instalowane ale mogłyby być poprostu
> > wymagane przez Makefile przy budowaniu instalatora. W tracie kompletowania
> > wszystkie za pomocą rpm2cpio całość mogłaby być rozpakowywana do
> > konkretnych katalogów czyli, że tego typu rpm-y mogły być poprostu
> > traktowane tylko jako archiwa.
> 
> Gwaratnuję ci, że jeśli tak zrobimy, to za 3-4 wersję wszystko
> przestanie działać, bo kto normalny budowałby --with BOOT po
> każdej zmianie?

Nikt. Powiem inaczej. To ma wylądać tak, że gemnerowanie instalak *tylko*
na podstawie zasobów z cvs powinno być wykonywane dokładnie może i nawet
codziennie i to automatycznie. Po to żeby każdy miał szybką i prosta drogę
do możliwie prostego rozszerzania/poprawiania instalki poprzez wyłącznie
modyfikowanie zasobów w repo.

> Szczególnie kernel. Równie dobrze można nie robić
> rpm'ów tylko budować sobie pakiety z Makefile, ale that's
> not a way to go.

Wygemnerowanie nawet dzień w dzień kilku pakietów w wersji BOOT nie będzie
mocno obciążające. MAkefile porafi nadzorować to co powinno być
przebudoewane o ile jakieś pliki maja nowszy time stamp. Jeżeli
doprowadzimy to do pełnego automatyzmu to całosć będzie bardzo przejrzysta
i powtarzalna w budowaniu. To są dwie cechy na których powinno w tym
momencie nam zależeć żeby kawałek po kawałeczku niemal dzień w dzień móc
coś tam zmodyfikować bez zaglądania i nadzorowania ręcznie całej
automatyki.

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*