[Clfs-dev] Embedded: Is e2fsprogs really needed in core embedded book?

[Andrew Bradford]

On Fri, Apr 8, 2011 at 9:54 PM, Joe Ciccone <jciccone at gmail.com> wrote:
> I propose creating a filesystems section under the beyond chapter and
> move e2fsprogs there. Tools for all the different filesystems can be
> added there, as many or as few as need be. ext*, jffs2, squash, reiser2,
> jfs, xfs, or whatever else you might find on an embedded board.

That's a good idea.  I opened trac ticket #832 for it.  I'll work on this.

>> This could be a good idea, provided there's an easy way to determine
>> which packages will actually work on the embedded build.  Regular CLFS
>> has quite a different set of packages and thus some basic dependencies
>> may not be met as easily with the embedded build.  If you've
>> successfully built any of the CBLFS packages for your embedded system,
>> please let me know.  I'm not sure if there's a good way to indicate a
>> package works with embedded on the CBLFS wiki.  If there is, update
>> that too, please.
>
> I'm not even sure if the embedded book should point at either BLFS or
> CBLFS. It's one of those things were you really can't follow either one.
> Especially for the embedded book because of uClibc. As compatible as it
> is with Glibc there are a lot of threading problems that always seem to
> come up.

I think if people are successful getting stuff to build and run
properly on an embedded build, it'd be nice to know.  I'm not sure of
the best format, (C)BLFS wiki versus book versus some other medium.

There was some discussion on IRC yesterday morning (like 7am EST)
about a project to do a CBLFS type thing for embedded because nothing
really provides that info for a uClibc system right now.  sjs205
(sorry, don't know your real name :( ) said it's something they are
interested in working on and I'd be willing to contribute, too.

Which then has to beg the question, would moving embedded to EGLIBC be
something to consider?  My impression is the 'E' stands for embedded,
but I'm not sure if it's as small as uClibc (I'm assuming it's not).
Other than using EGLIBC on Debian (since it comes with it), I've no
experience with it.  EGLIBC would provide much better compatibility
with "beyond" type packages, but at what cost?

-Andrew