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 1NFmQb-0001qj-B8 for garchives@archives.gentoo.org; Wed, 02 Dec 2009 10:27:21 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C201CE088D; Wed, 2 Dec 2009 10:27:11 +0000 (UTC) Received: from foo.birdnet.se (foo.birdnet.se [213.88.146.6]) by pigeon.gentoo.org (Postfix) with SMTP id 64BCCE088D for ; Wed, 2 Dec 2009 10:27:11 +0000 (UTC) Received: (qmail 20043 invoked by uid 501); 2 Dec 2009 10:27:08 -0000 Message-ID: <20091202102708.20042.qmail@stuge.se> Date: Wed, 2 Dec 2009 11:27:08 +0100 From: Peter Stuge To: gentoo-catalyst@lists.gentoo.org Subject: Re: [gentoo-catalyst] Catalyst stages inter-dependencies Mail-Followup-To: gentoo-catalyst@lists.gentoo.org References: <166af1cf0912020124o35468591y379900e7f900c9c2@mail.gmail.com> <20091202094414.13781.qmail@stuge.se> <166af1cf0912020207u7af47e10kdbb6543ab892404@mail.gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-catalyst@lists.gentoo.org Reply-to: gentoo-catalyst@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <166af1cf0912020207u7af47e10kdbb6543ab892404@mail.gmail.com> X-Archives-Salt: 9df616c5-8e5a-4202-ad69-49870e6594c8 X-Archives-Hash: fc86c7243adb793d08146c11b51802cf Shinkan wrote: > > No. If you had experimented a little with catalyst and spec files > > this is one of the things that you would have discovered immediately > > from the catalyst output. > > Pretty fair... I experimented "a little" with catalyst. Except if a > little means "more than 3 days". That's certainly a good deal of experimenting! I hoped that it would be clear from what catalyst outputs, that this is how it works. Glad to have helped clear it up though! > that mostly why mailing-lists come for : answering for more > experimented users feedback. Agree! No problem. Sorry for being a bit harsh. > > Every catalyst target uses a source tarball, and the created target > > will contain everything in that source tarball which you do not > > remove. > > OK so let's say I define a profile early. > If I build a stage1, I'll have to use a existing stage3. > Will this stage1 have stage3 files which are not removed ? No I think. Correct - I don't think it will. > But then if I want to build stage2, catalyst will be expecting stage1 > to be able to build stage2 isn't it ? Yes. > The point (since the begining), is that I don't want my base system > to have gcc and portage. I don't want to remove them : I don't want > them at all. In any stage. > So I really don't get why I would have to create a profile, stage1 > to stage4 > ... to still remove and unmerge gcc and portage at the end ! Again I think the answer is because catalyst offers many nice advantages, which warrants the extra trouble of having the toolchain in stage3 but remove it in stage4. (Since catalyst makes binpkgs the toolchain is only built the first time anyway.) > I think I don't get clear on my aim : > I want to make a build env with gcc/portage/all the build stuff. > From this env I want to build a target from scratch. > The target won't have build tools in it at any point. Why is this important in intermediate steps? > I don't want the usual Gentoo way where all stage is built by > preceding one, and is composed of preceding one. That is what catalyst does, so in that case it is not for you. Sorry for not understanding your requirements better. :\ > I want build place and target to be clearly separated, and I don't > wat to apply a "remove things" behavior to target. Well, as I mentioned before, it is certainly possible for you to add a kind of stage5, either using catalyst, or just with a single tar command. This final step would be run after the stage4 and every single file that you want to include in your final tarball would be explicitly named there. That way you get all the nice features of catalyst internally while building a target, but at the very end there is still an explicit, exclusive filter which names the files you want. Using this you don't even have to unmerge or remove, you can just leave everything in the stage4 and pick out the parts you want. You may not even need a stage4, you could possibly do all you need already in the stage3. > I try things with catalyst, I promise, including writing profile, > but I don't get to my aim. > And you still seems pretty sure that catalyst can do that ! It depends on if you have a strict requirement on the process, or on the final result. If the final result is the important thing, then catalyst can certainly be of help even though the internal process with several stages does not work like you describe. catalyst is more capable than emerge, but it does not extend _every_ feature of emerge, so there is currently no catalyst target which emerges into an empty root using a cross toolchain. Doing that is also much more difficult than the way existing catalyst targets work, and it is a fairly different aim from that of Gentoo release engineering, so there is no big reason for them to implement it. But maybe they will accept patches for it if someone else does it. Unless you do have these strict requirements not only on the final result but also the internals of the process then I would definately make use of catalyst if not exclusively then at least as the major workhorse of the build process. //Peter