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 A80B6138010 for ; Mon, 10 Sep 2012 03:24:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D0FFDE062C; Mon, 10 Sep 2012 03:24:44 +0000 (UTC) Received: from mail-iy0-f181.google.com (mail-iy0-f181.google.com [209.85.210.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 292D0E05E4 for ; Mon, 10 Sep 2012 03:23:32 +0000 (UTC) Received: by iagw33 with SMTP id w33so1523075iag.40 for ; Sun, 09 Sep 2012 20:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=hRDzeAH5OiN5hvmvE+kbANQ7FenxoT81iLSHzK42o74=; b=S7E+QIqCiKnTc9Cw53IO0ZNkDFMhVcByn1vwExGmCVz+lqBGs6MDC9uaV/gDMACmTT 8xyuDnVzrhYFmjpnlEszSukatMpAGukWJQ2diU35EElR1tuXQSkmMXxqutlsLgYc+8Cl l9/+j6G/JeysF9yOVgDRddvWnWbnNPpYj8wBm/QuaMoCqaSN0eLqaucuj7hlVvhIZZvD 9s5fmkW/0I25gZnuhvVccJ9MA1a7MyUcTF3N8ySWiAhVf0dPnLIJUt1EfVjzzo8RJOeK LIGHaGLBsvG0z1njnfpR6O2fH8KQKLOG0jaMCA6/nL5Tm91mrlrVPGWb+hmYXj9oICXJ Nw8Q== Received: by 10.50.169.70 with SMTP id ac6mr8921111igc.12.1347247412371; Sun, 09 Sep 2012 20:23:32 -0700 (PDT) Received: from smtp.gmail.com:587 (74-95-192-101-SFBA.hfc.comcastbusiness.net. [74.95.192.101]) by mx.google.com with ESMTPS id cu10sm17454688igc.9.2012.09.09.20.23.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 09 Sep 2012 20:23:29 -0700 (PDT) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Sun, 09 Sep 2012 20:23:35 -0700 Date: Sun, 9 Sep 2012 20:23:35 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: unifying use.mask/package.use.mask, use.force, package.use.force, etc Message-ID: <20120910032335.GB8036@localhost> References: <20120909221027.GA8036@localhost> 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=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 4cafc832-8d9d-4e50-bf05-e13fb7a664de X-Archives-Hash: 9c3b0bbdd9e88ad6c6e2d9ddf862c179 On Mon, Sep 10, 2012 at 01:28:23AM +0000, Duncan wrote: > Brian Harring posted on Sun, 09 Sep 2012 15:10:27 -0700 as excerpted: > > > [Current profile config to to mask the USE=introspection > > globally, but unmask it for app-crypt/gcr]: > > > > use.mask: > > introspection > > > > package.use.mask: > > app-crypt/gcr -introspection > > > [Suggest killing package.* content, folding it into use.*] > > > use.mask: > > * introspection > > app-cryt/gcr -introspection > > > Specifically, collapsing: > > package.use.mask, use.mask -> use.mask > > package.use.force, use.force -> use.force > > package.use.stable.mask, use.stable.mask -> use.stable.mask > > package.use.stable.force, use.stable.force -> use.stable.force > > You mention doing this for the profile. Not 'mention' the proposal *is a profiles modification* in entirety, nothing else. Reorganizing the questions into user configuration (aka, the PM authors choice of what they want to do in /etc/portage/profiles), and PMS profiles (aka, what can be done in gentoo-x86). user config first: > ?? Would user's package.* and general make.conf settings remain the same? That's the PM's decision. Knowing portage source, I'd expect it'll wind up enabling that in parallel to the existing for it's user configuration. > ?? What about user's existing /etc/portage/profile overrides, if any? Same response; that's the PMs decision. What Zac does, is what Zac does. > ?? And if they change, are you proposing a script that a user can run to > automate the process, or simply a news item pointing to the appropriate > gentoo profile upgrade documentation page, or ?? { cat use.mask | sed -e 's:^:* :'; cat package.use.mask; } > t \ && mv t use.mask && rm package.use.mask Actual PMS profiles question: > ?? Are you proposing the change be only for new profiles, eventually > deprecating the old ones, thus having the PMs (and devs maintaining > profiles) support both methods for awhile much as the cascading profiles > migration was handled? Profile nodes are EAPI versioned; what I want, is effectively >=EAPI-5 (or 6 if people get cranky about minor mods), is this to be the default in new EAPI profile nodes. Meaning if someone uses a EAPI5 profile node in gentoo-x86, they don't use package.use.mask, they use the syntax I mentioned, and do it within use.mask. There will not be maintaining in parallel; there isn't a point. Basically, this is a ~70 file reduction of profiles; 253 -> 184 roughly. Aside from less general IO (not much, but some), it also kills of the question for devs as to which comes first; use.mask or package.use.mask. Ordering of the file would rule in the new scheme. Frankly if we wanted to, we could push this further; use.force and use.mask basically operate in a ternary space: -1, 0, +1; meaning "Forced off", "configurable", and "enforced on"; respecitively such a syntax would be -use, use, +use. Thus the following: use.mask: blah -monkeys # Note this is a negation of the parents masking of 'monkeys' -foon # Negation of the parents masking package.use.mask: dev-util/bsdiff foon use.force: x -y # negation of the parents forcing monkeys # Note we're explicitly forcing monkeys on after reversing # masking package.use.force dev-util/diffball strip that translates out to basically thus: use.enforced: # This globally disables 'blah', globally forces 'monkeys', # and resets 'foon' back to user controllable. * -blah +monkeys foon # Disable blah for dev-util/bsdiff. dev-util/bsdiff -foon # Force strip for dev-util/diffball. dev-util/diffball +strip The benefit of such an aproach is that 1) I'd argue it's easier on the dev for processing it- just proceed top down, for the pkg in question considering if each leading restriction (* or the atom) matches, then applying the resultant settings. 2) This actually is basically what the PM does now, although it does so via grabbing the content from multiple files. In terms of performance gain, couldn't say frankly; pkgcore already does a variant of this, re-rendering each cat/pkg restriction set so as to avoid having to do the resolution multiple times (this helps repoman/pcheck speed for example). That said I'm not sure if folks would go for the ternary usage there. Where that scheme to be applied to our profiles, it'd knock the inode count for these files down to 127. Not the driving reason for it, but a nice benefit. ~harring