bin86 suggestion pertaining to lilo

Tushar Teredesai tush at yahoo.com
Mon Jul 8 15:45:28 PDT 2002


Andrew Friedley wrote:

>>Nice approach. But...
>>
>>What happens when a new version of lilo is released and the user wants
>>to upgrade?
>>    
>>
>you can prefix bin86 somewhere long enough to compile lilo again, then rm
>it.
>
>or you can just not upgrade and wait till a new lfs is necessary, which for
>something like lilo is what i favor, unless some kind of serious bug is
>found thatd necessitate a version upgrade - if that were to happen id do the
>above.
>
>as for the first suggestion, i do it all the time when upgrading stuff on my
>system.
>for example.. i prefix perl into /usr/perl long enough to run ./configure on
>openssl, then rm it to keep my system free of the (imho) evil of perl.
>irssi and glib are another example - i build glib static and link irssi
>against it, then rm it.
>  
>
Yeah, I also follow that approach for some packages. But that approach 
is not appropriate for the book. Based on that approach, I can install 
autoconf, automake, etc in /static once LFS and other packages are 
installed I can remove them. When I install a package that needs them, I 
can install them for the duration of the compilation and then remove them.

My opinion is that it is not an approach that should follow in the book. 
If package X depends on some package Y, Y should be installed. The book 
should either move to grub, and remove dev86 or stick with the current 
structure.

Just my 2cents.

-- 
Tushar Teredesai
LFS ID: 1377
http://www.geocities.com/tush/lfs/


-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list