public inbox for gentoo-catalyst@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-catalyst] Catalyst stages inter-dependencies
@ 2009-12-02  9:24 Shinkan
  2009-12-02  9:44 ` Peter Stuge
  0 siblings, 1 reply; 5+ messages in thread
From: Shinkan @ 2009-12-02  9:24 UTC (permalink / raw
  To: gentoo-catalyst

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

Hi everyone.

Just one simple question :
Let's say I want to use a base official gentoo stage3 to build a stage4 with
catalyst.
Let's say I wrote my own profile, which defines a very very minimal system
with no gcc, no portage, ..., and that I use this profile for stage4.
If I use catalyst stage4 spec file type, which takes a stage3 as a seed,
would my stage4 contains everything from stage3 (that I don't explicitely
remove), or would my stage4 be built from scratch by stage3 (and contains
just system ports my stage4 profile specified) ?

The same question goes for livecd.
Would my final livecd contain stage3 or livecd-stage1 build tools if I
define a minimal system profile for livecd-stage2 ?

Thanks in advance.

-- 
Pierre.
"Sometimes when I'm talking, my words can't keep up with my thoughts. I
wonder why we think faster than we speak. Probably so we can think twice." -
Bill Watterson

[-- Attachment #2: Type: text/html, Size: 1000 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [gentoo-catalyst] Catalyst stages inter-dependencies
  2009-12-02  9:24 [gentoo-catalyst] Catalyst stages inter-dependencies Shinkan
@ 2009-12-02  9:44 ` Peter Stuge
  2009-12-02 10:07   ` Shinkan
  0 siblings, 1 reply; 5+ messages in thread
From: Peter Stuge @ 2009-12-02  9:44 UTC (permalink / raw
  To: gentoo-catalyst

Shinkan wrote:
> Just one simple question :
> Let's say I want to use a base official gentoo stage3 to build a
> stage4 with catalyst.
> Let's say I wrote my own profile, which defines a very very minimal
> system with no gcc, no portage, ..., and that I use this profile
> for stage4.

This is an error. It may work, but if you are going to use a custom
profile you should create all stages where profile differences will
result in different contents than what release engineering produces.
This goes at least back to stage2 and maybe even stage1.


> If I use catalyst stage4 spec file type, which takes a stage3 as a
> seed, would my stage4 contains everything from stage3 (that I don't
> explicitely remove),

Yes.


> or would my stage4 be built from scratch by stage3 (and contains
> just system ports my stage4 profile specified) ?

No. If you had experimented a little with catalyst and spec files
this is one of the things that you would have discovered immediately
from the catalyst output.


> The same question goes for livecd.

The same answer.


> Would my final livecd contain stage3 or livecd-stage1 build tools
> if I define a minimal system profile for livecd-stage2 ?

Every catalyst target uses a source tarball, and the created target
will contain everything in that source tarball which you do not
remove.


This is why it is smart to create your own profile and build your own
early stages. That way your early stages will never include any of
the packages that are good for standard systems but which you do not
want in your final targets.


//Peter



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [gentoo-catalyst] Catalyst stages inter-dependencies
  2009-12-02  9:44 ` Peter Stuge
@ 2009-12-02 10:07   ` Shinkan
  2009-12-02 10:27     ` Peter Stuge
  0 siblings, 1 reply; 5+ messages in thread
From: Shinkan @ 2009-12-02 10:07 UTC (permalink / raw
  To: gentoo-catalyst

[-- Attachment #1: Type: text/plain, Size: 2062 bytes --]

2009/12/2 Peter Stuge <peter@stuge.se>

> No. If you had experimented a little with catalyst and spec files
> this is one of the things that you would have discovered immediately
> from the catalyst output.
>

Pretty fair... I experimented "a little" with catalyst. Except if a little
means "more than 3 days".
As I used unmerge and remove directives (as suggested by examples specs), I
could not figure it out easily, sorry I have to ask, but except if I get it
wrong, that mostly why mailing-lists come for : answering for more
experimented users feedback.


> Every catalyst target uses a source tarball, and the created target
> will contain everything in that source tarball which you do not
> remove.
>

OK so let's say I define a profile early.
If I build a stage1, I'll have to use a existing stage3.
Will this stage1 have stage3 files which are not removed ? No I think.
But then if I want to build stage2, catalyst will be expecting stage1 to be
able to build stage2 isn't it ?
The point (since the begining), is that I don't want my base system to have
gcc and portage. I don't want to remove them : I don't want them at all. In
any stage.
So I really don't get why I would have to create a profile, stage1 to stage4
... to still remove and unmerge gcc and portage at the end !


I think I don't get clear on my aim :
I want to make a build env with gcc/portage/all the build stuff. From this
env I want to build a target from scratch.
The target won't have build tools in it at any point.
I don't want the usual Gentoo way where all stage is built by preceding one,
and is composed of preceding one.
I want build place and target to be clearly separated, and I don't wat to
apply a "remove things" behavior to target.

I try things with catalyst, I promise, including writing profile, but I
don't get to my aim.
And you still seems pretty sure that catalyst can do that !


-- 
Pierre.
"Sometimes when I'm talking, my words can't keep up with my thoughts. I
wonder why we think faster than we speak. Probably so we can think twice." -
Bill Watterson

[-- Attachment #2: Type: text/html, Size: 2697 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [gentoo-catalyst] Catalyst stages inter-dependencies
  2009-12-02 10:07   ` Shinkan
@ 2009-12-02 10:27     ` Peter Stuge
  2009-12-02 13:22       ` Shinkan
  0 siblings, 1 reply; 5+ messages in thread
From: Peter Stuge @ 2009-12-02 10:27 UTC (permalink / raw
  To: gentoo-catalyst

Shinkan wrote:
> > No. If you had experimented a little with catalyst and spec files
> > this is one of the things that you would have discovered immediately
> > from the catalyst output.
> 
> Pretty fair... I experimented "a little" with catalyst. Except if a
> little means "more than 3 days".

That's certainly a good deal of experimenting!

I hoped that it would be clear from what catalyst outputs, that this
is how it works. Glad to have helped clear it up though!


> that mostly why mailing-lists come for : answering for more
> experimented users feedback.

Agree! No problem. Sorry for being a bit harsh.


> > Every catalyst target uses a source tarball, and the created target
> > will contain everything in that source tarball which you do not
> > remove.
> 
> OK so let's say I define a profile early.
> If I build a stage1, I'll have to use a existing stage3.
> Will this stage1 have stage3 files which are not removed ? No I think.

Correct - I don't think it will.


> But then if I want to build stage2, catalyst will be expecting stage1
> to be able to build stage2 isn't it ?

Yes.


> The point (since the begining), is that I don't want my base system
> to have gcc and portage. I don't want to remove them : I don't want
> them at all. In any stage.
> So I really don't get why I would have to create a profile, stage1
> to stage4
> ... to still remove and unmerge gcc and portage at the end !

Again I think the answer is because catalyst offers many nice
advantages, which warrants the extra trouble of having the toolchain
in stage3 but remove it in stage4. (Since catalyst makes binpkgs the
toolchain is only built the first time anyway.)


> I think I don't get clear on my aim :
> I want to make a build env with gcc/portage/all the build stuff.
> From this env I want to build a target from scratch.
> The target won't have build tools in it at any point.

Why is this important in intermediate steps?


> I don't want the usual Gentoo way where all stage is built by
> preceding one, and is composed of preceding one.

That is what catalyst does, so in that case it is not for you. Sorry
for not understanding your requirements better. :\


> I want build place and target to be clearly separated, and I don't
> wat to apply a "remove things" behavior to target.

Well, as I mentioned before, it is certainly possible for you to add
a kind of stage5, either using catalyst, or just with a single tar
command. This final step would be run after the stage4 and every
single file that you want to include in your final tarball would be
explicitly named there.

That way you get all the nice features of catalyst internally while
building a target, but at the very end there is still an explicit,
exclusive filter which names the files you want. Using this you don't
even have to unmerge or remove, you can just leave everything in the
stage4 and pick out the parts you want. You may not even need a
stage4, you could possibly do all you need already in the stage3.


> I try things with catalyst, I promise, including writing profile,
> but I don't get to my aim.
> And you still seems pretty sure that catalyst can do that !

It depends on if you have a strict requirement on the process, or on
the final result. If the final result is the important thing, then
catalyst can certainly be of help even though the internal process
with several stages does not work like you describe.

catalyst is more capable than emerge, but it does not extend _every_
feature of emerge, so there is currently no catalyst target which
emerges into an empty root using a cross toolchain. Doing that is
also much more difficult than the way existing catalyst targets work,
and it is a fairly different aim from that of Gentoo release
engineering, so there is no big reason for them to implement it. But
maybe they will accept patches for it if someone else does it.

Unless you do have these strict requirements not only on the final
result but also the internals of the process then I would definately
make use of catalyst if not exclusively then at least as the major
workhorse of the build process.


//Peter



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [gentoo-catalyst] Catalyst stages inter-dependencies
  2009-12-02 10:27     ` Peter Stuge
@ 2009-12-02 13:22       ` Shinkan
  0 siblings, 0 replies; 5+ messages in thread
From: Shinkan @ 2009-12-02 13:22 UTC (permalink / raw
  To: gentoo-catalyst

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

2009/12/2 Peter Stuge <peter@stuge.se>

>
> Agree! No problem. Sorry for being a bit harsh.
>

Thanks a lot for taking time answering on each subject I needed help for.
But above it all, this answer is the most clear and understanding.


>
> > I think I don't get clear on my aim :
> > I want to make a build env with gcc/portage/all the build stuff.
> > From this env I want to build a target from scratch.
> > The target won't have build tools in it at any point.
>
> Why is this important in intermediate steps?
>

Because I'll need some targets to run against a specific version glibc.
I don't really know how to do that, but I guess I must compile target with
correct target gcc/glibc.
Then, I'll have to build some bin packages for just one or two port for this
target, so I guess I have to preciously keep my build envs.


>
> Well, as I mentioned before, it is certainly possible for you to add
> a kind of stage5, either using catalyst, or just with a single tar
> command. This final step would be run after the stage4 and every
> single file that you want to include in your final tarball would be
> explicitly named there.
>

That's quite a good idea. I'll think about it.


>
> It depends on if you have a strict requirement on the process, or on
> the final result. If the final result is the important thing, then
> catalyst can certainly be of help even though the internal process
> with several stages does not work like you describe.
>

That really helps. It's the good question.
As I'm not alone to decide, I'll have to ask.



-- 
Pierre.
"Sometimes when I'm talking, my words can't keep up with my thoughts. I
wonder why we think faster than we speak. Probably so we can think twice." -
Bill Watterson

[-- Attachment #2: Type: text/html, Size: 2669 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2009-12-02 13:23 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-02  9:24 [gentoo-catalyst] Catalyst stages inter-dependencies Shinkan
2009-12-02  9:44 ` Peter Stuge
2009-12-02 10:07   ` Shinkan
2009-12-02 10:27     ` Peter Stuge
2009-12-02 13:22       ` Shinkan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox