Randy McMurchy wrote:
Dan Nicholson wrote these words on 01/10/06 12:41 CST:
Those are good picks since there is a lot of linking to these packages
in BLFS. A special policy would have to be approved, though.
It is not so much a policy being approved, it would be more a method
of *how to do it*. Would it just be a mention of the stuff that really
isn't important to the build, yet you might like to know?
Now, don't start saying things like, "Well, I don't build DB or Perl
or Readline or ... when I build my LFS". Quite frankly, that doesn't
matter if you aren't following the LFS book.
Sure, we'd like to help as many as possible, and hope that our book
is effective for those other than who've built LFS, but from a
maintainability standpoint, it would simply be impossible.
Where would it end? Reader X wants LFS package A, B, and C listed
in BLFS. Reader Y wants package D, E and F listed. And so forth
and so on.
On the other hand, adding dependency info about LFS packages to BLFS now
would make things somewhat easier when an LFS package is removed or
replaced. Perhaps, to cover people who don't build every LFS package as
well as the future possibility of an LFS package being remove or
replaced, a certain minimal number of packages could be considered to be
obviously necessary for a working linux system capable of building
additional software from source - glibc, gcc, binutils, make (you could
also add coreutils, gawk, patch, bash, grep, and sed, which are also
needed to compile most packages, and gzip, bzip2, and tar, for obvious
reasons)- and don't list those dependencies, but list everything else.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
