On 5/20/12 2:18 PM, Bryan Kadzban wrote:
> In other words, I think it'd help to only use packages to simplify
> (mostly BLFS) testing, but make them semi-public for people who really
> want them. Don't use them at all in the actual build instructions (what
> would be the point? :-) ), but generate the spec files, or whatever
> equivalent, from the book XML. (This last bit might be either hard or
> impossible; I don't know.)
Yes - I believe you have hit exactly what I'm trying to propose. The
binaries (and binary repository) aren't advertised in any way for
general use - they aren't even mentioned in the build instructions.
For example, consider this as a very simplified version of a package page:
"Build package Blah:
Manually:
./configure ...
make
(Optionally, via package tool):
# Grab generated spec file here...
./makepkg
"
And then the spec file, would have references to the dependency packages
in BLFS, calling them exactly how they've been referenced in the book's
source. I suppose here the 'optional' ones could be enabled or disabled
by a reader. As would devs - although I think for dev purposes it might
be useful to have built binaries with all optional dependencies enabled.
Behind the scenes, a set of tools and a defined workflow can help the
devs to share binaries already produced via the spec files - but those
are never explicitly shared or brought to the attention of the reader.
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
