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

[David Seikel]

I've got to the stage where I'm actually writing the app that is the
device I'm being paid to develop, now that I have enough OS to actually
support running it on real hardware.  One of the reasons I chose EFL as
the graphic framework is that it's happy running on framebuffer or X.
So now I can develop the app in my comfortable X environment, and test
it every now and then on the real hardware and it's frame buffer.

Which means I now have two development streams, and I can switch
between them as needed, more or less independently.  Polish the OS,
and write the app.

For the polish the OS part, I'm thinking about how to split things into
"stuff needed at run time to support the app", and "stuff needed at
compile time to compile everything".  Which brings me on topic.

On Sun, 19 Jun 2011 13:20:25 -0500 Rob Landley <rob at landley.net> wrote:

> So I'm poking at lfs-bootstrap this weekend, and my design assumptions
> seem to have crossed paths and cancelled each other out at some point.

Cool.  I'm yet to update to the latest Aboriginal version, but I should
this week.

I have been thinking about those tags you have in the package list, and
what to do about them.  The "# busybox" tags seem to be more useful as
a comment about why some LFS package was not built, it's functionality
being provided by busybox.

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.

Problem number one is just basic - where should this mount point
be?  /usr/devel strikes me as a good choice for reasons I wont go into
unless someone thinks otherwise.

Next is that while the includes from all the other packages should
likely go into /usr/devel, libs may or may not.  Compile time libs and
libs used statically yes, dynamic libs no.  Will the user compile
everything only statically?  For my project, parts of EFL don't like
being compiled static, so I'm compiling the app dynamically.

I think Rob mentioned something about how to actually drive it all.

> Which means I should look at the current uClibc release again to see
> if signal handling sucks less under NPTL.  But lemme re-establish an
> LFS native build baseline first.  And possibly update it to the
> current LFS release...

I'm in two minds about that.  I'm using GRUB, and had to back up to the
last LFS that still used "legacy" GRUB.  On the other hand, I have
stripped out most of LFS, either using busybox, or just dumping stuff
that is not relevant.  Those small parts of LFS I have left are the
version from Aboriginal, and the GRUB I'm using seems happy about that.

Meh, lets see what happens with what you produce.

> P.S.  I used to post this kind of stuff to my blog, but I'm trying to
> post it here now.  Lemme know if you have a preference where it should
> go?  If I do post it here, the list traffic is mostly me blathering on
> about technobabble details, but if I blog it the list traffic tends to
> get really sparse and the comments I get about it are in private email
> instead of here...

Saves me having to deal with your blog stuff that is not about
Aboriginal development.  I'm a compulsive reader, and avoiding
temptation is always good.  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/aboriginal-landley.net/attachments/20110620/647bc3af/attachment-0002.pgp>