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

[Tomasz Kłoczko]

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.
 
> > > 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.
W ogólnym przypadku Makefile organizujący generowanie instalki mógłby
także sam zapuścić zaciagnięcie builderem źródeł pakietów i ich
przebudowanie z --with BOOT.
Budowanie kernel-x.x.x-x_BOOT warunkowo takze skracałoby czas potrzebny na
produkcje odpowiednich binarek.
Tak czy inaczej mnożenie kolejnych pakietów obecnych na ftp nie jest IMHO
za dobrym rozwiązaniem i raczej wartoby szukać innych/prostrzych metod na
powyższe. Wszystko to tylko dlatego, że robienie instalek to zadanie dość
specyficzne co w tym wypadku usprawiedliwia inne podejście do całosci.

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*