From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1PMnPe-0004v2-1R for garchives@archives.gentoo.org; Sun, 28 Nov 2010 19:59:54 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EC36BE06C8; Sun, 28 Nov 2010 19:59:39 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 4A96AE055D for ; Sun, 28 Nov 2010 19:59:02 +0000 (UTC) Received: from [192.168.22.4] (ip68-4-152-120.oc.oc.cox.net [68.4.152.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPSA id 8A9AE1B423B; Sun, 28 Nov 2010 19:59:01 +0000 (UTC) Message-ID: <4CF2B489.6020207@gentoo.org> Date: Sun, 28 Nov 2010 11:59:05 -0800 From: Zac Medico User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b3pre Thunderbird/3.1.6 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 To: gentoo-dev@lists.gentoo.org CC: Gentoo Council Subject: Re: [gentoo-dev] Extending EAPI="4" References: <201010251524.24984.Arfrever@gentoo.org> <4CE69CE7.6040907@gentoo.org> <201011281915.59713.Arfrever@gentoo.org> In-Reply-To: <201011281915.59713.Arfrever@gentoo.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: f8acf0b1-ed12-4740-a6b7-a13381ab5c89 X-Archives-Hash: 64238edc56def7068dbf0f2abae06a94 On 11/28/2010 10:15 AM, Arfrever Frehtes Taifersar Arahesis wrote: > 2010-11-19 16:51:03 Zac Medico napisa=C5=82(a): >> On 10/25/2010 06:24 AM, Arfrever Frehtes Taifersar Arahesis wrote: >>> use.unsatisfiable and package.use.unsatisfiable files would cause tha= t `repoman` would treat >>> given USE flags in the same way as masked USE flags. These files woul= dn't affect behavior of >>> `emerge`: >>> - If user has enabled given USE flag specified in use.unsatisfiable = or package.use.unsatisfiable >>> and if optional dependencies controlled by this USE flag are alrea= dy installed or satisfiable, >>> then `emerge` will allow to install given package. >>> - If user has enabled given USE flag specified in use.unsatisfiable = or package.use.unsatisfiable >>> and if optional dependencies controlled by this USE flag cannot be= satisfied (with current >>> settings of ACCEPT_KEYWORDS, /etc/portage/package.keywords etc.), = then `emerge` will print >>> informative error message telling e.g. about a dependency masked b= y ~${ARCH} keyword. >> >> Can't we print a "masked by ~${ARCH} keyword" message as you suggest, >> even without the use.unsatisfiable data? If so, then isn't >> use.unsatisfiable redundant? Your patch [1] seems to behave exactly li= ke >> use.mask, so I don't see any value added. >=20 > repoman sometimes needs to allow stable packages to have optional depen= dencies on unstable > packages (usually until these packages are stabilized). My patch implem= ents this functionality > for repoman. It seems like you're trying to bypass an important function of repoman though. The idea is that repoman is supposed to protect users from experiencing unsatisfiable dependencies of this sort, and use.mask accomplishes that. With your use.unsatisfiable patch, it makes repoman quiet, while leaving users unprotected from unsatisfied dependencies. --=20 Thanks, Zac