From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27658 invoked from network); 3 Dec 2004 00:42:45 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 3 Dec 2004 00:42:45 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1Ca1X2-0006yd-Rt for arch-gentoo-dev@lists.gentoo.org; Fri, 03 Dec 2004 00:42:44 +0000 Received: (qmail 24772 invoked by uid 89); 3 Dec 2004 00:42:44 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 22844 invoked from network); 3 Dec 2004 00:42:44 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Date: Thu, 02 Dec 2004 17:42:39 -0700 Organization: Sometimes Message-ID: References: <20041201222109.GA20954@vicerveza.homeunix.net> <20041202110107.GA27739@vicerveza.homeunix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-66-193.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news Subject: [gentoo-dev] Re: Re: About linux-headers, making stages with catalyst X-Archives-Salt: b965ad02-b7e7-4cf0-838b-4d42cd359998 X-Archives-Hash: a8063c135caf1dac685f4bb13dcc75b8 Lluís Batlle i Rossell posted <20041202110107.GA27739@vicerveza.homeunix.net>, excerpted below, on Thu, 02 Dec 2004 12:01:07 +0100: > What I've tried, while answering this email: I've tried using 2004.3 => > Still keeps on using 2.4 (there are no virtual definitions in 2004.3!) > I've tried using default-linux/x86/2004.2/gcc34/2.6/ as profile => Even > this way emerge still keeps on using 2.4 > I've tried changing the content of the virtuals in default-linux and > default-linux/x86 => YES! Now it installs 2.6 headers. > > But... Shouldn't the other tries work ??? At least, you say that about > 2004.3, and the profile ....gcc34/2.6/ seems to have virtuals defined > there. OK, I see statements CG's statement that no x86 profile defaults to 2.6 headers for the virtuals, that he knows of, but you point out profiles/default-linux/x86/2004.2/gcc34/2.6/, as I did. Where a virtual is required, cascading profiles should read parent dirs until they find the default, if it's not in the current profile dir. Thus, the lack of a virtual definition file (or one not including all necessary virtuals) shouldn't be alarming, as it should just look up-tree to fill the requirement. Because profiles/default-linux/x86/2004.3 has a 2.4 subdir, and I'd seen discussion on the dev group/list on switching to 2.6 by default, I wrongly concluded 2004.3 on x86 had done so. It appears I was wrong. As you mention, there's no virtuals there, so it looks up-tree, to x86, where it finds virtual/linux-sources defaults to sys-kernel/gentoo-sources. That covers the kernel virtual default, but not headers, so it looks up-tree another notch, and finds them under default-linux, where virtual/os-headers defaults to sys-kernel/linux-headers. Note that it /also/ mentions virtual/kernel, defaulting that to sys-kernel/vanilla-sources. This means that we have three separate virtuals provided. virtual/os-headers defaults to the 2.4 series linux-headers. However, we have TWO DIFFERENT virtuals for kernel, virtual/kernel, and virtual/linux-sources. I'm GUESSING these should be one and the same, but in any case, they both default to 2.4 series kernels altho different branches of the series. Which one (or both) would try to be merged would therefore be dependent on which virtual individual packages called for. I thought to simplify matters, quickly clarifying which /should/ be used, by checking my arch, amd64. However, the virtuals file there only ADDS to the confusion, because instead of virtual/kernel pointing to a kernel, it points to headers. Of course the 2.4 kernel is depreciated on amd64, so everything points to 2.6 versions, but both virtual/os-headers and virtual/kernel point to sys-kernel/linux26-headers, while virtual/linux-sources points to sys-kernel/gentoo-dev-sources. Thus, virtual/kernel points to kernel sources in the one place, and only kernel headers in another, which is certainly confusing me! Anyway, back to x86, it indeed appears that profiles/default-linux/x86/2004.2/gcc34/2.6 defaults to 2.6 versions of both headers and kernel: virtual/kernel sys-kernel/linux26-headers virtual/os-headers sys-kernel/linux26-headers virtual/linux-sources sys-kernel/gentoo-dev-sources Hmm.. here too we have virtual/kernel pointing to headers, not sources, as in amd64, but NOT as the default-linux virtuals file, where virtual/kernel points to kernel sources instead of just kernel headers. Anyway, it would seem that profiles/default-linux/x86/2004.2/gcc34/2.6 does what you want, PROVIDED you don't have any problems with gcc-3.4, which is of course what the gcc34 refers to. That sub-profile defines all three virtuals, kernel, headers, and sources, to 2.6 defaults. Note that catalyst most likely will *NOT* notice the changed profile, unless you erase its previous tmp files. I'm suspecting that's the other problem you are experiencing now. It has its config, and doesn't go looking to change that, unless it disappears. Therefore, after changing your profile to the above 2004.2/gcc34/2.6, erase catalyst's temp files and see if it recreates them using the desired 2.6 minimals, now. Alternatively and the reason catalyst (again, presumably) works as it does, is that it allows you to modify its temp file virtuals once it gets past that point, thus allowing you to build a live-cd with a modified profile, without affecting the build-system's profile. Thus, instead of erasing the tmp files so catalyst sees the new configuration, consider editing the catalyst version directly instead. However, I'd say do as little editing here as possible, because it's possible tweaking one thing there will cause something else problems. An example would be tweaking the headers virtual to linux26-headers, while leaving the kernel at 2.4 virtuals. Gentoo's pre-built profiles should have those sort of dependencies worked out, while editing them could cause problems due to interlinking dependencies you weren't aware of when you did the editing. Thus, I'd recommend doing the above, change the system profile and erase catalyst's tmp files so it regenerates from that, instead of manually tweaking its profile, preventing potentially nasty surprises with conflicting dependencies. Also... you mention changing the content of the virtuals. You don't mention specifically /where/ you changed that content, in the catalyst temp files (OK), or directly in the portage tree itself (not so OK). The problem with changing it in the portage tree is that an emerge sync will erase the changes you made (unless you have rsync-ignore set on that dir, which creates problems of its own if Gentoo changes anything). For a one-shot catalyst build, and as long as you don't go doing an emerge sync while it's running, you should be fine, but just be aware that emerge sync /will/ erase changes you've made to the profiles in the portage tree itself. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin -- gentoo-dev@gentoo.org mailing list