Re: [gentoo-embedded] Cross Dev Tricks + Hardened questions

[Peter Stuge]

Shinkan wrote:
> > 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.

No problem. Just specify the versions you want in your stage2. Of
course you need those ebuilds somewhere, but that can easily be in an
overlay.


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

I agree it's a bit of a hack. But it will work very well until you
upgrade catalyst, at which point you should probably be prepared to
review your spec files anyway.


> 2) Each of my target can be different. WCS, we have one profile per
> target, per architecture, per type of target... per version.

I don't quite understand this, since you haven't given very many
details about what you want to do.


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

Can profiles be in an overlay by the way? In that case you don't have
to mess with symlinks at all, and could still use inheritance.


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

catalyst does not implement any caching of it's own. The caching is
all done by emerge, and can be used fine also without catalyst.


> Because I will do nasty things on the portage tree.

Then you must expect everything to break.


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

This is not proper use of portage and ebuilds. Please read a bit
about how version numbers are handled in ebuilds. If you make local
additions to an upstream version you shall append -r1 to the ebuild
version. Next local change to same upstream version shall be -r2, and
so on.


> Cache is really a killing feat of catalyst, but I can't afford it
> for my things. I fear the cache.

I think you should learn how it works instead, so that you can take
full advantage of it.

If you create proper ebuilds and follow the rules for ebuild
versioning, you will find that the cache works wonderfully well.

(Again, the "cache" is simply emerge --usepkg --buildpkg.)


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

Yes, I know this. Please read again what I wrote.

Your stage4 will not have a build environment.


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

No.

You would start by creating a stage1 or stage2 spec file. stage1
might not be neccessary, stage2 may be enough.

A stage2 spec file starts from a stage1 tarball.
A stage2 spec file makes catalyst build toolchain and libc.

A stage3 spec file starts from the stage2 tarball produced above.
A stage3 spec file normally installs some basic packages. Your stage3
may in fact be a no-op. But stuff like iproute2 could be here.

A stage4 spec file starts from the stage3 tarball produced above.
A stage4 spec file normally installs anything beyond the basic
system, and cleans out all unwanted things. The stage4 also builds a
kernel.

Since all your stages would be minimal, there is not a lot of
cleaning, so re-running the stage4 will also not take very long time.

In the profile and in most if not all stage spec files you will
specify the packages you want for that stage.


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

That's ok. I admit that this would need different sets of spec files
for catalyst, but you'd also need different scripts if doing it
manually.


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

This is why I wrote earlier that I think you should make some
experiments and see for yourself what it can do. catalyst is not
really a very advanced tool - it just collects all the small tasks in
a single utility, which makes it very handy.


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

You'll have to do a bit more than that, but not too much. 5 or so
spec files, including the one for the CD. Create the profile, the
configuration files that you want of course. In any case you also
have to create an overlay for local ebuilds. I find layman very easy
to work with. There's an XML file for my overlay at
http://stuge.se/overlay.xml


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

I guess this is kind of what I proposed. Create a new target type or
types, other than stage1..4 and livecd1,2, which do not start from a
source stage, but start from an empty directory. But someone has to
do it, and I think releng are pretty busy doing their own job.
(catalyst is their tool.)


//Peter