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

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

I wanted to say for instance "gcc-3.4.3" and not "current gcc".
Because I want some targets to be built against a specific version of glibc.


>
>
> > 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?
>

I thought about that. But :
1) That's a dirty hack. What if gentoo decides to put profiles in
/usr/portage/boringstuffs/profiles/ ?
They can because of official transparent "eselect profile" way of selecting
a profile.
2) Each of my target can be different. WCS, we have one profile per target,
per architecture, per type of target... per version.
I want my target build env to be self-containing, so I don't want 10K
profiles moving around my host tree.
Plus, I lost profiles parenting if I put things in /etc/catalyst/mytarget/


>
> > - 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.
>

I would have to audit catalyst code to tell cache won't break some of my
needs.
Because I will do nasty things on the portage tree. I don't want catalyst to
think it can "pick a bin in a cache" (that's sound funny isn't it ?), but in
fact ebuild with same version has changed because of some patches I applied.
Cache is really a killing feat of catalyst, but I can't afford it for my
things. I fear the cache.


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

That's fine. But I can do this with simple emerges too.


> "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.
>

I don't want my "stage4" to have a build env. I want my stage4 to be very
minimal.
I would expect catalyst to do this in fact :
1) Take a official stage3.
2) Build a build env with this stage3. Build env would have specified
arch/gcc/libc/binutils version, and portage with a specified tree.
3) From this build env, catalyst would build a target with JUST the packages
I specified, so the target would be totally empty at begining.
Then I would like the kernel comp on build env, and image cped to my target.
Then I would like catalyst to emerge kernel dependant packages to my target.
Then I would be done with a "stage4", which is my target.
4) Then my target could be put on a live cd with some more mechanic catalyst
already offers.
For all step there would be a spec file, and possibility to specify each
dest dirs.


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

Hey that was a little rude I think !


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

I confirm in my case it would work. I build on amd64, I target x86 and
amd64, but with different glibc bases.


> 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..
>

I really liked catalyst when I read it spec examples.
After dealing a little with basic scenarios and totally outdated examples, I
started to find that I had needs it can't answer.
I was really sad, I promise.
What I miss the most is the "I will just have to write 2 spec files per
target, YAY !!!" dream, and the "I take care of the Live CD boring stuffs".

Catalyst should provide a "solar glasses stuffed cowboy" mode, where it
could act as an evolved spec-files base cross compiler/emerger, and where we
could build from nothing.

-- 
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