| 1 |
> Well, catalyst was designed to build a gentoo image. I want to build |
| 2 |
> embedded images that have nothing gentoo specific about them. No |
| 3 |
> portage, no python, no eselect or anything else like that. |
| 4 |
|
| 5 |
Actually (and speaking with no real experience), I believe it can build |
| 6 |
exactly that... However, it's big and complicated as solutions go (also |
| 7 |
there is the tool from Funtoo) |
| 8 |
|
| 9 |
|
| 10 |
>> Patching ebuilds in mind: I have been experimenting with |
| 11 |
>> /etc/portage/patches and also the bashrc for broad patching, eg where |
| 12 |
>> some long standing patch or config customisation is necessary (eg delete |
| 13 |
>> some openrc file which makes no sense, or customise some udev config, |
| 14 |
>> etc) |
| 15 |
> I've never heard of that file, '/etc/portage/patches', and can't find it |
| 16 |
> in man portage. |
| 17 |
|
| 18 |
Just create /etc/portage/patches/net-dns/dnscache/somepatch.patch |
| 19 |
|
| 20 |
In theory the docs said that if the file was called |
| 21 |
dnscache-1.2.3-mypatch.patch, then it would only apply to that version |
| 22 |
number, but for me it seems all patches are applied (I rename them to |
| 23 |
exclude them) |
| 24 |
|
| 25 |
Additionally the hooks for each stage of portage are accessible from |
| 26 |
/etc/portage/bashrc |
| 27 |
|
| 28 |
|
| 29 |
> There always is a learning curve for embedded and it will be impossible |
| 30 |
> to support every single configuration for every single board. Basically |
| 31 |
> my plan was to try to logically split all the steps in making a |
| 32 |
> filesystem image and put them into a clear well documented bash script, |
| 33 |
|
| 34 |
Sure - actually I just have a base file called "mod", that includes your |
| 35 |
"recipe" file and then it calls functions: mount_deps(), build(), |
| 36 |
target(), unmount_deps() from the recipe file. It's the provider of the |
| 37 |
recipe's job to fill in each of those functions |
| 38 |
|
| 39 |
It means I can call "./mod build 0.1" repeatedly (the number is the |
| 40 |
package version number) until I'm happy and then call "./mod target |
| 41 |
0.1", etc |
| 42 |
|
| 43 |
> I can drop what a have so far into a git repo and we can go from there |
| 44 |
> taking the best from each of our scripts. Do you want to make the repo |
| 45 |
> or should I? |
| 46 |
|
| 47 |
I think you should knock up some repo (probably github is a good choice |
| 48 |
because it's so easy to fork). |
| 49 |
|
| 50 |
If you are interested I will email over some samples of my small scripts |
| 51 |
and you can see if they are interesting to work into your basic environment? |
| 52 |
|
| 53 |
Cheers |
| 54 |
|
| 55 |
Ed W |
Archives