From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NFb8E-0004Ye-Gu for garchives@archives.gentoo.org; Tue, 01 Dec 2009 22:23:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 27A84E0DFB for ; Tue, 1 Dec 2009 22:23:38 +0000 (UTC) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by pigeon.gentoo.org (Postfix) with ESMTP id 5AEC7E0C58 for ; Tue, 1 Dec 2009 20:53:17 +0000 (UTC) Received: by fxm7 with SMTP id 7so4751786fxm.29 for ; Tue, 01 Dec 2009 12:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=+p8VTLXPD3fbhoKbVtqRKwhQX+FvrNCFLMKjlvjogtw=; b=C1EtGAnMATnOxBKUKhYaScb+Hg/FvsNEUqZQzR8uNkxpVq6dbJTfYVOEHFqHaWpyc8 pxnuta7RJhY1/1VsGcbBuMIeRDAVfWtGUPsvUnaRbAac/Vx341u9EYPxUmgqEsLsW5U4 CNMF6F+/8Vo70Hxb1QhgW2xziH+SD+RG1ARCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=LdsD2n8jejea6Qe8epbmpVAuIBnPa4/LBqTfHq6m1VrtKJdQpdPYl35VAefDlpp3b9 G1onv4rY1AWO+3Xc0cEAsFnWrTi5W7jjMIAXQYHudgmGag1gTQ3CZXZmolfQMWz+Tgv1 ED3RSzjalhSnTwOi8djtLUvlpaZ+f7lc+2NI4= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-embedded@lists.gentoo.org Reply-to: gentoo-embedded@lists.gentoo.org MIME-Version: 1.0 Received: by 10.223.68.155 with SMTP id v27mr953125fai.10.1259700796153; Tue, 01 Dec 2009 12:53:16 -0800 (PST) In-Reply-To: <20091201190307.18265.qmail@stuge.se> References: <166af1cf0911301024s61e229a6h9116c00ad84673e8@mail.gmail.com> <20091130211241.27358.qmail@stuge.se> <1259689712.4071.1.camel@hangover> <166af1cf0912010044l5ecf11ebkcc93dbbfe4603ebc@mail.gmail.com> <20091201190307.18265.qmail@stuge.se> From: Shinkan Date: Tue, 1 Dec 2009 21:52:56 +0100 Message-ID: <166af1cf0912011252l7fba8d6fqa4f6624e89be4727@mail.gmail.com> Subject: Re: [gentoo-embedded] Cross Dev Tricks + Hardened questions To: gentoo-embedded@lists.gentoo.org Content-Type: multipart/alternative; boundary=001517475b507a5f030479b0f2ef X-Archives-Salt: 15517380-ebc6-46ab-b591-acdebf83cc1b X-Archives-Hash: b2e81117b6d1f6f8a7a940557a0f8d86 --001517475b507a5f030479b0f2ef Content-Type: text/plain; charset=UTF-8 2009/12/1 Peter Stuge > 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 --001517475b507a5f030479b0f2ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 f= or instance "gcc-3.4.3" and not "current gcc".
Becau= se I want some targets to be built against a specific version of glibc.
=C2=A0


> 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<= br> and give a relative path like ../../../etc/catalyst/mytarget/profile
in the catalyst spec file?

I thought about that. B= ut :
1) That's a dirty hack. What if gentoo decides to put profiles = in /usr/portage/boringstuffs/profiles/ ?
They can because of official tr= ansparent "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 b= uild env to be self-containing, so I don't want 10K profiles moving aro= und my host tree.
Plus, I lost profiles parenting if I put things in /etc/catalyst/mytarget/<= br>=C2=A0

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

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


> =C2=A0 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= 9;s sound funny isn't it ?), but in fact ebuild with same version has c= hanged because of some patches I applied.
Cache is really a killing feat of catalyst, but I can't afford it for m= y things. I fear the cache.
=C2=A0
Right. I get tbz2s which I install on my target.

T= hat's fine. But I can do this with simple emerges too.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> "system" is not a great term. Yes, your stage4 will not have a bu= ild
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 mini= mal.
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 th= is build env, catalyst would build a target with JUST the packages I specif= ied, 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 t= arget.
Then I would be done with a "stage4", which is my targe= t.
4) Then my target could be put on a live cd with some more mechanic catalys= t already offers.
For all step there would be a spec file, and possibili= ty to specify each dest dirs.
=C2=A0

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

Hey t= hat was a little rude I think !
=C2=A0

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 t= arget 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 f= ind that I had needs it can't answer.
I was really sad, I promise.
What I miss the most is the "I will ju= st have to write 2 spec files per target, YAY !!!" dream, and the &quo= t;I take care of the Live CD boring stuffs".
=C2=A0
Catalyst s= hould provide a "solar glasses stuffed cowboy" mode, where it cou= ld act as an evolved spec-files base cross compiler/emerger, and where we c= ould 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 sp= eak. Probably so we can think twice." - Bill Watterson
--001517475b507a5f030479b0f2ef--