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 |