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 B22A51392EF for ; Thu, 3 Jul 2014 07:32:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F402AE0878; Thu, 3 Jul 2014 07:32:31 +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 E8F13E0872 for ; Thu, 3 Jul 2014 07:32:30 +0000 (UTC) Received: from pomiot.lan (77-255-6-176.adsl.inetia.pl [77.255.6.176]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 2298933FCF2; Thu, 3 Jul 2014 07:32:28 +0000 (UTC) Date: Thu, 3 Jul 2014 09:32:13 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: Joshua Kinard Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] new profile layout with flavors and mix-ins Message-ID: <20140703093213.7ff896af@pomiot.lan> In-Reply-To: <53B4F5AF.9020600@gentoo.org> References: <20140702154416.GA1151@linux1> <20140702195437.09c8efdb@pomiot.lan> <53B4F5AF.9020600@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-pc-linux-gnu) 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: multipart/signed; micalg=pgp-sha512; boundary="Sig_/Jf1KbfHeT+meqmmpXk+9Wbi"; protocol="application/pgp-signature" X-Archives-Salt: b37bceb8-5b92-48dd-8bef-c512cb8569ea X-Archives-Hash: e4406f24ff690b41ba1088e82deae16a --Sig_/Jf1KbfHeT+meqmmpXk+9Wbi Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-07-03, o godz. 02:18:23 Joshua Kinard napisa=B3(a): > [...] > > And so on. The goal was to have profiles/ be extremely flat, with limited > nesting only for categorization purposes. Each component would contain a= ll > of the information specific to that component, and rely on OOP-like > inheritance to override parent-level variables only within that component > (although, and would have to be a little bit more broad in > scope). Another sub-thread, the same question: how do you handle information that needs to be applied to the intersection of the profiles? CHOST for amd64 FreeBSD, for example. > PROFILE also had a set order for the first few pieces, if only to make > parsing and building the profile stack saner for the Portage developers: > PROFILE=3D"base::[:]::" >=20 > base - Core Gentoo/Portage/whatever information/vars/foobar/kittens I'm against plain 'base' since it quickly becomes a mess. I would prefer having flavor-specific bases, like for example arch/base to mask stuff available only in 1/2 arches and revert it in another arch/. > kernel - Specifies the OS kernel. At the time, only Linux existed, but > I *think* Debian was eyeballing kFreeBSD at the time. So I *thi= nk* > I accounted for it back then. What about kernel-ABI intersection? What about Prefix? > arch - Machine arch-specific generic information -- doesn't handle > lower-level things like ISAs/ABIs/Endian, etc. >=20 > subarch - Defines items specific given to given subarch of a main arch. > Items under this directory would carry their parent arch's > name for clarity only. Again, at the time, MIPS would have been > the only real user of this, and, back then, it would've dealt > with SGI-machine-specific packages and USE flags, such as > differentiating an ip32 machine from an ip27 machine or a > cobalt. Now that amd64/x86_64 is considering its own form of > n32 (x32), that would go here, and I imagine arm would > make heavy use of it as well. This is a no-go for multilib support. We need to work on a consistent arch profile tree, not more splitting. > libc - Defines the main C library used. A bit redundant for *BSD, because > they really only have one, but might help if we ever add k*BSD > support (such as freebsd/glibc-based or such). For Linux...could = be > tricky, since there are so many libc possibilities there. I feel = it > fits better getting defined after , especially in the case > of MIPS. I think you need to handle kernel & libc in the same group. > eapi - EAPI didn't exist back when this topic was visited. Basically, > everything was EAPI=3D0 and there was only Portage (Paludis nor > pkgcore had been invented yet). And what is this supposed to do? > releases - I don't think this existed back then. How it'd operate > nowadays, I have no idea. Probably would contain > version-specific maskings for specific @system packages > to facilitate upgrading, and help us if we ever tried to cut > actual, fixed release points again (like what FreeBSD does > w/ -RELEASE-x.y) I don't think releases would make any sense without heavy intersection with other profiles. --=20 Best regards, Micha=B3 G=F3rny --Sig_/Jf1KbfHeT+meqmmpXk+9Wbi Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJTtQcCXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOTEYQANdtXS1Dk6A4EYTOV9ijAPrE JIKJKWCJmJPIWimKLSFnw3uQkdJszCqTx977TgblWo2cde9pYr8nf4yV+FtT9DG0 PSOD5+JsQ9kZm52KJH6s9znlrF62Dw4aBL3aGTShGyXAoPOA8qXf6kLN4+DdgHiN RWGZJTwbwjJ0TIm2xxJdqdMBcKlLh9uIfzhFL231vpWpEYqUZUN4HwmU+EAj1Igy ndpk2Ny9xERzk29yTVOC1jAUTR1z1btdLMwrBUBI4Hsz7eO8J+FaR+U9Bjz7Cao3 NRi1okjRoD/L9g0ncD6lG3ZnJT5WXN4zXIpJdr7yj1Wg3jGb4ZslQXOq/rmMGh1n XgMgf285RAvtcidEastkn1I3YoGlQlIIAgvrciFboMnaGJ/HGqGqK4SXamPi1qQG wxXHBaOdRbaiaOTVdBawMcz4CZIpk7KwugGymr4P3Tlx0IQ5KjIxCImxCYk8bsfU 6Yj8C51MHYID/IxtcvujccwSR95p4uoJeeiI4caIbNuK2mO1d9H0VJCJVK3XsZxx KuMy8oSJhJgwiLEQlNLN3zvtjqjyBmdwwkEUknFlTub6hVzAR++8NICBhV6yTjDR 0tuT40jNXuNSMDrUqh7hRsDz9r6/h5Zo0YZClTK7mAHurGxNTb7YUviuI+q3CYus kwUQrOL8QFdJSuBZgxIs =BdOg -----END PGP SIGNATURE----- --Sig_/Jf1KbfHeT+meqmmpXk+9Wbi--