Re: [gentoo-embedded] generating root file systems

[Ed W <lists@wildgooses.com>]

> Well, catalyst was designed to build a gentoo image. I want to build
> embedded images that have nothing gentoo specific about them. No
> portage, no python, no eselect or anything else like that.

Actually (and speaking with no real experience), I believe it can build
exactly that...  However, it's big and complicated as solutions go (also
there is the tool from Funtoo)


>> Patching ebuilds in mind: I have been experimenting with
>> /etc/portage/patches and also the bashrc for broad patching, eg where
>> some long standing patch or config customisation is necessary (eg delete
>> some openrc file which makes no sense, or customise some udev config,
>> etc)
> I've never heard of that file, '/etc/portage/patches', and can't find it
> in man portage.

Just create /etc/portage/patches/net-dns/dnscache/somepatch.patch

In theory the docs said that if the file was called
dnscache-1.2.3-mypatch.patch, then it would only apply to that version
number, but for me it seems all patches are applied (I rename them to
exclude them)

Additionally the hooks for each stage of portage are accessible from
/etc/portage/bashrc


> There always is a learning curve for embedded and it will be impossible
> to support every single configuration for every single board. Basically
> my plan was to try to logically split all the steps in making a
> filesystem image and put them into a clear well documented bash script,

Sure - actually I just have a base file called "mod", that includes your
"recipe" file and then it calls functions: mount_deps(), build(),
target(), unmount_deps() from the recipe file.  It's the provider of the
recipe's job to fill in each of those functions

It means I can call "./mod build 0.1" repeatedly (the number is the
package version number) until I'm happy and then call "./mod target
0.1", etc

> I can drop what a have so far into a git repo and we can go from there
> taking the best from each of our scripts. Do you want to make the repo
> or should I?

I think you should knock up some repo (probably github is a good choice
because it's so easy to fork).

If you are interested I will email over some samples of my small scripts
and you can see if they are interesting to work into your basic environment?

Cheers

Ed W