| 1 |
2009/12/1 Peter Stuge <peter@×××××.se> |
| 2 |
|
| 3 |
> Hm, what is ports version? Do you mean the portage snapshot? That can |
| 4 |
> be set in the spec files though? |
| 5 |
> |
| 6 |
|
| 7 |
I wanted to say for instance "gcc-3.4.3" and not "current gcc". |
| 8 |
Because I want some targets to be built against a specific version of glibc. |
| 9 |
|
| 10 |
|
| 11 |
> |
| 12 |
> |
| 13 |
> > I really don't want to build a profile because they're hard to |
| 14 |
> > maintain in a wide use scheme, and because that's overkill. |
| 15 |
> |
| 16 |
> Would it not work to put a profile in /etc/catalyst/mytarget/profile |
| 17 |
> and give a relative path like ../../../etc/catalyst/mytarget/profile |
| 18 |
> in the catalyst spec file? |
| 19 |
> |
| 20 |
|
| 21 |
I thought about that. But : |
| 22 |
1) That's a dirty hack. What if gentoo decides to put profiles in |
| 23 |
/usr/portage/boringstuffs/profiles/ ? |
| 24 |
They can because of official transparent "eselect profile" way of selecting |
| 25 |
a profile. |
| 26 |
2) Each of my target can be different. WCS, we have one profile per target, |
| 27 |
per architecture, per type of target... per version. |
| 28 |
I want my target build env to be self-containing, so I don't want 10K |
| 29 |
profiles moving around my host tree. |
| 30 |
Plus, I lost profiles parenting if I put things in /etc/catalyst/mytarget/ |
| 31 |
|
| 32 |
|
| 33 |
> |
| 34 |
> > - I want to be able to just emerge one new port or update one on a |
| 35 |
> > target, and with Catalyst I cant. |
| 36 |
> |
| 37 |
> Sure you can. I do this a lot with my systems. |
| 38 |
> |
| 39 |
> |
| 40 |
> > I must rebuild all (yeah, cache is there but...), |
| 41 |
> |
| 42 |
> But what? I find that the most time is spent in the rsync, done first |
| 43 |
> for a catalyst stage. Binpkgs install very quickly. |
| 44 |
> |
| 45 |
|
| 46 |
I would have to audit catalyst code to tell cache won't break some of my |
| 47 |
needs. |
| 48 |
Because I will do nasty things on the portage tree. I don't want catalyst to |
| 49 |
think it can "pick a bin in a cache" (that's sound funny isn't it ?), but in |
| 50 |
fact ebuild with same version has changed because of some patches I applied. |
| 51 |
Cache is really a killing feat of catalyst, but I can't afford it for my |
| 52 |
things. I fear the cache. |
| 53 |
|
| 54 |
|
| 55 |
> Right. I get tbz2s which I install on my target. |
| 56 |
> |
| 57 |
|
| 58 |
That's fine. But I can do this with simple emerges too. |
| 59 |
|
| 60 |
|
| 61 |
> "system" is not a great term. Yes, your stage4 will not have a build |
| 62 |
> environment, so the next catalyst run will take a little longer. |
| 63 |
> Maybe that's a big problem in your scenario, but if you can live with |
| 64 |
> that, I don't see a problem. |
| 65 |
> |
| 66 |
|
| 67 |
I don't want my "stage4" to have a build env. I want my stage4 to be very |
| 68 |
minimal. |
| 69 |
I would expect catalyst to do this in fact : |
| 70 |
1) Take a official stage3. |
| 71 |
2) Build a build env with this stage3. Build env would have specified |
| 72 |
arch/gcc/libc/binutils version, and portage with a specified tree. |
| 73 |
3) From this build env, catalyst would build a target with JUST the packages |
| 74 |
I specified, so the target would be totally empty at begining. |
| 75 |
Then I would like the kernel comp on build env, and image cped to my target. |
| 76 |
Then I would like catalyst to emerge kernel dependant packages to my target. |
| 77 |
Then I would be done with a "stage4", which is my target. |
| 78 |
4) Then my target could be put on a live cd with some more mechanic catalyst |
| 79 |
already offers. |
| 80 |
For all step there would be a spec file, and possibility to specify each |
| 81 |
dest dirs. |
| 82 |
|
| 83 |
|
| 84 |
> |
| 85 |
> Ned Ludd wrote: |
| 86 |
> > catalyst can do none of the above |
| 87 |
> |
| 88 |
|
| 89 |
Hey that was a little rude I think ! |
| 90 |
|
| 91 |
|
| 92 |
> |
| 93 |
> In this case it will work, since build is amd64 and target x86. |
| 94 |
> |
| 95 |
|
| 96 |
I confirm in my case it would work. I build on amd64, I target x86 and |
| 97 |
amd64, but with different glibc bases. |
| 98 |
|
| 99 |
|
| 100 |
> Hey - another, more novel, idea would be to create some new catalyst |
| 101 |
> targets, that combines both these methods and builds from nothing, |
| 102 |
> but with direction. |
| 103 |
> |
| 104 |
> I insist on catalyst because it takes care of a good deal of things |
| 105 |
> that have to be done manually otherwise - documentation, filesystem |
| 106 |
> overlay, create binpkgs, create tarball, create iso.. |
| 107 |
> |
| 108 |
|
| 109 |
I really liked catalyst when I read it spec examples. |
| 110 |
After dealing a little with basic scenarios and totally outdated examples, I |
| 111 |
started to find that I had needs it can't answer. |
| 112 |
I was really sad, I promise. |
| 113 |
What I miss the most is the "I will just have to write 2 spec files per |
| 114 |
target, YAY !!!" dream, and the "I take care of the Live CD boring stuffs". |
| 115 |
|
| 116 |
Catalyst should provide a "solar glasses stuffed cowboy" mode, where it |
| 117 |
could act as an evolved spec-files base cross compiler/emerger, and where we |
| 118 |
could build from nothing. |
| 119 |
|
| 120 |
-- |
| 121 |
Pierre. |
| 122 |
"Sometimes when I'm talking, my words can't keep up with my thoughts. I |
| 123 |
wonder why we think faster than we speak. Probably so we can think twice." - |
| 124 |
Bill Watterson |
Archives