Gentoo Archives: gentoo-embedded

From: Ed W <lists@××××××××××.com>
To: gentoo-embedded@l.g.o
Subject: Re: [gentoo-embedded] generating root file systems
Date: Wed, 13 Jul 2011 16:11:50
In Reply to: Re: [gentoo-embedded] generating root file systems by Christopher Harvey
> 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