Shinkan wrote:
> I already looked a lot into Catalyst but some points doesn't fit to
> my plans :
> - I have to use a profile if I want to specify things (for instance
> ports version) for base stage.

Hm, what is ports version? Do you mean the portage snapshot? That can
be set in the spec files though?


> I really don't want to build a profile because they're hard to
> maintain in a wide use scheme, and because that's overkill.

Would it not work to put a profile in /etc/catalyst/mytarget/profile
and give a relative path like ../../../etc/catalyst/mytarget/profile
in the catalyst spec file?


> - Catatalyst seems to build by substraction (I mean on livecd, it
>   builds from a stage3, then unmerges and removes things). I want
>   to build with additive steps (from nothing).

catalyst starts somewhere too, and it uses spec files (written by
you) to create all stages. You would create your own stage3, which
would suit your needs. And a stage4. And probably use the stage4 as
source for the livecd.


> - I want to be able to just emerge one new port or update one on a
>   target, and with Catalyst I cant.

Sure you can. I do this a lot with my systems.


>   I must rebuild all (yeah, cache is there but...),

But what? I find that the most time is spent in the rsync, done first
for a catalyst stage. Binpkgs install very quickly.


>   and I really need to build just one port on some cases.

Right. I get tbz2s which I install on my target.


> That's why I thought about a "build" directory built from my host
> with crossdev. Then I use this build env to build my target with
> gcc/libc I want. If I have to build just one port, I can use my
> build env for this target again.

It also works, but I think there are nice benefits with catalyst.


> Since I choose what to build from nothing, I don't have to use
> profile to define what I put in my target or build. I don't break
> system by removing things.

"system" is not a great term. Yes, your stage4 will not have a build
environment, so the next catalyst run will take a little longer.
Maybe that's a big problem in your scenario, but if you can live with
that, I don't see a problem.


> My build standard "make.conf" serves as usual, I have nothing more
> than a crossdev, a make.conf filling, and some emerge to a given
> root.
> 
> That's what I want, but I don't know how to achieve this.

profile, stage1, stage2, stage3 and stage4. I agree that it is a
detour, but it does solve the problem.


> If Catalyst can offer me this control, I would be glad to use it.

Ned Ludd wrote:
> catalyst can do none of the above

catalyst can produce the same result, but it needs different input of
course.


> and it's not cross-compile aware at all.

In this case it will work, since build is amd64 and target x86.


> Building from nothing is the right way to handle what you
> are trying to accomplish.

The (big, I think) benefit with catalyst is that it gathers all
recipes and files and configuration in a single tool.

Of course, emerge can be scripted, but that seems like what catalyst
is already doing, right? ;)


Hey - another, more novel, idea would be to create some new catalyst
targets, that combines both these methods and builds from nothing,
but with direction.

I insist on catalyst because it takes care of a good deal of things
that have to be done manually otherwise - documentation, filesystem
overlay, create binpkgs, create tarball, create iso..


//Peter

Reply via email to