From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id B387813877A for ; Thu, 3 Jul 2014 08:53:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EA7BCE088B; Thu, 3 Jul 2014 08:53:37 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 06D63E0872 for ; Thu, 3 Jul 2014 08:53:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 2511233FE17 for ; Thu, 3 Jul 2014 08:53:36 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5.5 tests=[AWL=-1.156, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCgJWB7XL5fk for ; Thu, 3 Jul 2014 08:53:28 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id F2B0B33FE22 for ; Thu, 3 Jul 2014 08:53:27 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1X2cld-0006pp-Iz for gentoo-dev@gentoo.org; Thu, 03 Jul 2014 10:53:21 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 Jul 2014 10:53:21 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 Jul 2014 10:53:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: new profile layout with flavors and mix-ins Date: Thu, 3 Jul 2014 08:53:06 +0000 (UTC) Message-ID: References: <20140702154416.GA1151@linux1> <20140702195437.09c8efdb@pomiot.lan> <53B4F5AF.9020600@gentoo.org> <53B4FF82.4020309@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT d447f7c /m/p/portage/src/egit-src/pan2) X-Archives-Salt: c433653f-1a9a-417a-aee1-2a7cc75d1018 X-Archives-Hash: 485bbf513a247de39795a5a0c02d8a1c Michael Haubenwallner posted on Thu, 03 Jul 2014 09:00:18 +0200 as excerpted: > What about making /etc/portage/make.profile a directory rather than a > symlink, having /etc/portage/make.profile/parent to reference all the > flavours? We /almost/ have that already. I've long thought that /etc/portage/ profile should be the "real" profile instead of an override of the real profile, in which case it would have a parent file as you suggested, which could have multiple listed parents. Then /etc/portage/make.profile could be done away with, or more likely at least for a time, for compatibility reasons simply be a symlink -> profile. Then users would simply directly modify their /etc/portage/profile profile, including its parent file, as desired, instead of having the /etc/portage/make.profile symlink, with /etc/portage/profile being yet another layer on top of that. For all I know that might actually work right now as I've not tried it, but the portage (5) manpage does specifically say /etc/portage/profile supports all profile files EXCEPT parent, so unless the documentation is wrong... Assuming the documentation is correct, however, "all" we'd need to do on the user side would be to make portage and the other tools treat the parent file in /etc/portage/profile just as they do in other profile dirs, create an eselect module or equivalent to help manage that parent file, and update the documentation including the handbook accordingly. Updating other tree related tools would be required as well, of course, but as already pointed out, the real work would probably be in designing and setting up the new "flatter" profile tree layout and finding the appropriate new-layout location for all the existing settings. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman