| 1 |
Shinkan wrote: |
| 2 |
> > No. If you had experimented a little with catalyst and spec files |
| 3 |
> > this is one of the things that you would have discovered immediately |
| 4 |
> > from the catalyst output. |
| 5 |
> |
| 6 |
> Pretty fair... I experimented "a little" with catalyst. Except if a |
| 7 |
> little means "more than 3 days". |
| 8 |
|
| 9 |
That's certainly a good deal of experimenting! |
| 10 |
|
| 11 |
I hoped that it would be clear from what catalyst outputs, that this |
| 12 |
is how it works. Glad to have helped clear it up though! |
| 13 |
|
| 14 |
|
| 15 |
> that mostly why mailing-lists come for : answering for more |
| 16 |
> experimented users feedback. |
| 17 |
|
| 18 |
Agree! No problem. Sorry for being a bit harsh. |
| 19 |
|
| 20 |
|
| 21 |
> > Every catalyst target uses a source tarball, and the created target |
| 22 |
> > will contain everything in that source tarball which you do not |
| 23 |
> > remove. |
| 24 |
> |
| 25 |
> OK so let's say I define a profile early. |
| 26 |
> If I build a stage1, I'll have to use a existing stage3. |
| 27 |
> Will this stage1 have stage3 files which are not removed ? No I think. |
| 28 |
|
| 29 |
Correct - I don't think it will. |
| 30 |
|
| 31 |
|
| 32 |
> But then if I want to build stage2, catalyst will be expecting stage1 |
| 33 |
> to be able to build stage2 isn't it ? |
| 34 |
|
| 35 |
Yes. |
| 36 |
|
| 37 |
|
| 38 |
> The point (since the begining), is that I don't want my base system |
| 39 |
> to have gcc and portage. I don't want to remove them : I don't want |
| 40 |
> them at all. In any stage. |
| 41 |
> So I really don't get why I would have to create a profile, stage1 |
| 42 |
> to stage4 |
| 43 |
> ... to still remove and unmerge gcc and portage at the end ! |
| 44 |
|
| 45 |
Again I think the answer is because catalyst offers many nice |
| 46 |
advantages, which warrants the extra trouble of having the toolchain |
| 47 |
in stage3 but remove it in stage4. (Since catalyst makes binpkgs the |
| 48 |
toolchain is only built the first time anyway.) |
| 49 |
|
| 50 |
|
| 51 |
> I think I don't get clear on my aim : |
| 52 |
> I want to make a build env with gcc/portage/all the build stuff. |
| 53 |
> From this env I want to build a target from scratch. |
| 54 |
> The target won't have build tools in it at any point. |
| 55 |
|
| 56 |
Why is this important in intermediate steps? |
| 57 |
|
| 58 |
|
| 59 |
> I don't want the usual Gentoo way where all stage is built by |
| 60 |
> preceding one, and is composed of preceding one. |
| 61 |
|
| 62 |
That is what catalyst does, so in that case it is not for you. Sorry |
| 63 |
for not understanding your requirements better. :\ |
| 64 |
|
| 65 |
|
| 66 |
> I want build place and target to be clearly separated, and I don't |
| 67 |
> wat to apply a "remove things" behavior to target. |
| 68 |
|
| 69 |
Well, as I mentioned before, it is certainly possible for you to add |
| 70 |
a kind of stage5, either using catalyst, or just with a single tar |
| 71 |
command. This final step would be run after the stage4 and every |
| 72 |
single file that you want to include in your final tarball would be |
| 73 |
explicitly named there. |
| 74 |
|
| 75 |
That way you get all the nice features of catalyst internally while |
| 76 |
building a target, but at the very end there is still an explicit, |
| 77 |
exclusive filter which names the files you want. Using this you don't |
| 78 |
even have to unmerge or remove, you can just leave everything in the |
| 79 |
stage4 and pick out the parts you want. You may not even need a |
| 80 |
stage4, you could possibly do all you need already in the stage3. |
| 81 |
|
| 82 |
|
| 83 |
> I try things with catalyst, I promise, including writing profile, |
| 84 |
> but I don't get to my aim. |
| 85 |
> And you still seems pretty sure that catalyst can do that ! |
| 86 |
|
| 87 |
It depends on if you have a strict requirement on the process, or on |
| 88 |
the final result. If the final result is the important thing, then |
| 89 |
catalyst can certainly be of help even though the internal process |
| 90 |
with several stages does not work like you describe. |
| 91 |
|
| 92 |
catalyst is more capable than emerge, but it does not extend _every_ |
| 93 |
feature of emerge, so there is currently no catalyst target which |
| 94 |
emerges into an empty root using a cross toolchain. Doing that is |
| 95 |
also much more difficult than the way existing catalyst targets work, |
| 96 |
and it is a fairly different aim from that of Gentoo release |
| 97 |
engineering, so there is no big reason for them to implement it. But |
| 98 |
maybe they will accept patches for it if someone else does it. |
| 99 |
|
| 100 |
Unless you do have these strict requirements not only on the final |
| 101 |
result but also the internals of the process then I would definately |
| 102 |
make use of catalyst if not exclusively then at least as the major |
| 103 |
workhorse of the build process. |
| 104 |
|
| 105 |
|
| 106 |
//Peter |
Archives