[Aboriginal] Why more/chroot-splice.sh doesn't work anymore.

[Rob Landley]

On 06/20/2011 04:43 AM, David Seikel wrote:
> On Mon, 20 Jun 2011 19:36:09 +1000 David Seikel <onefang at gmail.com>
> wrote:
> 
>> The "# development" tag is much more interesting.  These are things
>> that could be built into some mountable directory somewhere, such that
>> it can be unplugged, leaving just the built system and an empty mount
>> point.
> 
> Oops, forget to mention - separating the development part of the result
> from the run time part is part of the scope of my contract.  So I'll
> likely be poking at that soonish.
> 
> The reason why lfs-bootstrap is still relevant to my project is that
> it's an example, starting point, and useful tools.  My variation of it
> for this project tries to stick with working the same way.  So
> developing this for one, works for the other. B-)

I made it modular intentionally.  Any package builds you feel like
pushing upstream, I'm happy to take a look at.

That said, I don't want to fall into the distro trap.  If the bootstrap
examples get too out of control, I'll kick 'em into their own repository
and try to convince somebody else to maintain them. :)

And _that_ said, Linux From Scratch itself is very well maintained, and
"bootstrap-gentoo", "bootstrap-debian", "bootstrap-fedora" are all well
defined sub-projects with a clear stopping point.  Part of the reason I
HAVEN'T done a blfs-bootstrap yet is doing the whole thing is too big
and fuzzily-defined subsets don't have a bright line constraining their
growth...

Adding configuration knobs to lfs-bootstrap so it can put the dev
packages in a subdir and not replace the busybox stuff is acceptable.
Adding packages that aren't IN Linux From Scratch is a much harder sell.
 (I see the utility, but that way lies OpenEmbedded.  speaking of which,
I want to do an openembedded-bootstrap control image.  Bitbake is like
portage and rpm and dpkg, give it an environment and let it build its
repo natively...)

Rob