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 4B6CC138010 for ; Mon, 10 Sep 2012 01:29:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 83107E058A; Mon, 10 Sep 2012 01:29:49 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 0382021C00C for ; Mon, 10 Sep 2012 01:28:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 8CB1E33C919 for ; Mon, 10 Sep 2012 01:28:46 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.448 X-Spam-Level: X-Spam-Status: No, score=-1.448 tagged_above=-999 required=5.5 tests=[AWL=-1.447, RP_MATCHES_RCVD=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dc755rvNDJsR for ; Mon, 10 Sep 2012 01:28:36 +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 31AD133C82B for ; Mon, 10 Sep 2012 01:28:36 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TAsnl-0008Bb-0f for gentoo-dev@gentoo.org; Mon, 10 Sep 2012 03:28:37 +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 ; Mon, 10 Sep 2012 03:28:37 +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 ; Mon, 10 Sep 2012 03:28:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: unifying use.mask/package.use.mask, use.force, package.use.force, etc Date: Mon, 10 Sep 2012 01:28:23 +0000 (UTC) Message-ID: 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=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.139 (Sexual Chocolate; GIT 4162e82 /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: 16d011fe-e9b8-41ca-ba00-3ff3fe1ec0f2 X-Archives-Hash: 404f40275590359ccc365f75bb453792 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. ?? Would user's package.* and general make.conf settings remain the same? ?? What about user's existing /etc/portage/profile overrides, if any? ?? 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? By definition, at least user's current /etc/ portage/profile/ settings are in the current format, so if you continue to support that, you'll in effect continue to support the old profile format, and (from the PM viewpoint) migration might as well be via new profiles and current profile deprecation, but that will force profile maintainers to maintain both for whatever period. ?? 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 ?? In general, the idea seems like an eventual efficiency gain and I'm not opposed, but I do wonder if the gain is actually going to be worth it in practice, given the above. Still, I'm not opposed, but I tend to be rather more leading edge and less opposed to change than most users in any case, and I'd guess a significant number of both users and devs that will be trying to support them (and both sets of profiles if the profile deprecation and upgrade migration method is chosen), will have rather stronger ideas about the practical cost/benefit ratio of such a change. -- 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