bin86 suggestion pertaining to lilo
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
>you can prefix bin86 somewhere long enough to compile lilo again, then rm
>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
>as for the first suggestion, i do it all the time when upgrading stuff on my
>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
Just my 2cents.
LFS ID: 1377
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