From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18337 invoked by uid 1002); 5 Aug 2003 00:01:49 -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 19635 invoked from network); 5 Aug 2003 00:01:49 -0000 X-Authentication-Warning: email: Host grizzly.ps.uni-sb.de [134.96.186.68] claimed to be ps.uni-sb.de To: gentoo-dev@gentoo.org From: Denys Duchier Date: Tue, 05 Aug 2003 01:56:55 +0200 Message-ID: <86u18xx9h4.fsf@speedy.ps.uni-sb.de> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Subject: [gentoo-dev] per package settings (proposal?) X-Archives-Salt: e1c34104-7e0b-4b38-b25e-e055fb2e35ad X-Archives-Hash: a06b5f3ea102c7c693e518f8a2c11367 Hi devs, Correct me if I am mistaken, but, as far as I know, there is no convenient way to accept ~arch on a per package basis. I have seen this issue frequently raised, and I certainly encounter the problem regularly on my own Gentoo installation, but I have not seen a proposal to address it. ACCEPT_KEYWORDS=3D~arch unfortunately also affects recursive dependencies. Personally, I find the situation very painful. A related issue are per package USE flags, or more generally per package settings. Here is an idea (perhaps it has already been suggested, in which case please point me to right place): Just like we now have /etc/portage/package.unmask, lets also have: /etc/portage/package.env It would consist of "hunks". Each hunk start with a package selection condition and the following lines consist of variable assignments. To reliably identify the start of a hunk let's say that there must be an asterisk in column 0. So a hunk might look for example like: * >=3Dcategory/package-version var1=3Dval1 var2=3Dval2 ... varn=3Dvaln for simplicity, I suggest either of the following semantics: 1. either, only the first matching hunk applies to a particular ebuild 2. or, all matching hunks apply (last setting for a variable wins) I prefer option 1. A particularly useful application would be: * >=3Dcategory/package-version ACCEPT_KEYWORDS=3D"~x86" USE=3D"..." Obviously, the idea would be that the variables settings would only apply for (have scope over) the specific ebuild, not over its dependencies. Is this foolish? already done? in the works? worth doing? Cheers, --=20 Dr. Denys Duchier =C9quipe Calligramme LORIA, Nancy, FRANCE -- gentoo-dev@gentoo.org mailing list