1 |
Pierre, |
2 |
|
3 |
Please don't top-post. |
4 |
|
5 |
|
6 |
Shinkan wrote: |
7 |
> I thought Catalyst could do the exact same thing with a more |
8 |
> Gentoo-ish way and sort-of cache settings. |
9 |
|
10 |
Yes, that is also a good summary of what I wrote. |
11 |
|
12 |
|
13 |
> But I'm still not sure. |
14 |
|
15 |
Be sure. |
16 |
|
17 |
|
18 |
> Here are the 2 crucial points that I don't want to evade : |
19 |
> 1) I do not want to build with a "deploy base Gentoo system, then |
20 |
> remove" strategy |
21 |
.. |
22 |
> 2) I do not want my target system to bootstrap itselfs |
23 |
.. |
24 |
> Can catalyst still do the job ? |
25 |
|
26 |
For the fourth time: catalyst does what you want. |
27 |
|
28 |
It creates a stage tarball according to instructions in a spec file. |
29 |
It uses emerge to build and install all packages in the stage. It |
30 |
saves binary packages of everything that has been built to save time |
31 |
if you want to make changes and run catalyst again. You specify how |
32 |
you want the tarball (or livecd) to be produced, by adding |
33 |
information to the spec file. |
34 |
|
35 |
|
36 |
> Why exactly should I make a profile ? |
37 |
|
38 |
Because your target or guest system will be sufficiently different |
39 |
from what the Gentoo profiles are intended for. |
40 |
|
41 |
|
42 |
In your case another idea is to create a simple script that runs |
43 |
after the stage4 is completed. Then you will not unmerge, empty or rm |
44 |
anything in the stage4 spec file, but use your script to create the |
45 |
deployment tarball with only the specific binaries and libraries that |
46 |
you want. Of course avoiding the script has the big advantage that |
47 |
you can encapsulate everything in a spec file and have catalyst |
48 |
generate the final product, but it will have a long list with lots of |
49 |
files that should _not_ be included. Having your own profile helps in |
50 |
shortening that list too. |
51 |
|
52 |
|
53 |
//Peter |