From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 202E81382C5 for ; Sat, 24 Mar 2018 07:03:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2A6D6E0882; Sat, 24 Mar 2018 07:03:12 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C9752E087C for ; Sat, 24 Mar 2018 07:03:11 +0000 (UTC) Received: from katipo2.lan (unknown [203.86.205.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id 8CCF7335C0A for ; Sat, 24 Mar 2018 07:03:09 +0000 (UTC) Date: Sat, 24 Mar 2018 20:02:39 +1300 From: Kent Fredric To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny Message-ID: <20180324200239.24cde39f@katipo2.lan> In-Reply-To: <23220.56500.47110.798699@a1i15.kph.uni-mainz.de> References: <1521745426.836.25.camel@gentoo.org> <20180322214732.GA4096@eddy> <1521756383.23424.0.camel@gentoo.org> <23220.52565.280134.566970@a1i15.kph.uni-mainz.de> <0559e21f-edcb-986f-0a0b-1bc54bc169a6@gmail.com> <23220.56500.47110.798699@a1i15.kph.uni-mainz.de> Organization: Gentoo X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; 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-sha256; boundary="Sig_/xwCMdUTVlR+M93diBYDctVi"; protocol="application/pgp-signature" X-Archives-Salt: 70c09be5-69d7-4787-8ce5-6cee59fbf56a X-Archives-Hash: 502d6caf7cc7b53482d76135ef5676e3 --Sig_/xwCMdUTVlR+M93diBYDctVi Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 23 Mar 2018 11:53:40 +0100 Ulrich Mueller wrote: > Still, masking is the wrong way to express such preferences. If you > package.mask sys-devel/gcc then you say that something is wrong with > that package. Which I believe is not what you want to express here. I might have a better usecase for adding masks from overlays. But its more for the usecase of "there isn't something wrong with that package", but the more frequent usecase of "Portage is stupid and so we have masks to coerce the right behaviour" For example, if I had an overlay that's sole purpose was to test/transition experimental versions of Perl, where the presumption was that by installing said overlay, that you wished to upgrade to that version of Perl, it might make sense to employ masks to prevent portage doing dumb things. And by "Dumb things", I mean some of the common problems I see where portage tries to solve a blocker by downgrading Perl.... Its much simpler to just author a blacklist of "Look, these are things that are known to be a mess, don't even consider installing them, with a nice description of why this is nonsense" Trying to achieve it by any other means simply tempts the problem to reappear in another form, because everything *other* than package.mask will have portage try to flip the USE flag to try to make it work, and end up with people needing --backtrack=3D1000 and having it still not work. package.mask is at least a "look, we know this is nonsense, don't even explore this line of reasoning" blunt instrument. --Sig_/xwCMdUTVlR+M93diBYDctVi Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPZazbI/qrFT1o9rn6FQySxNmqCAFAlq1+BwACgkQ6FQySxNm qCDFoQ/+Mk/6HgmBoY27HYrxcfiYPZALkZDI3TDHbJIcchqvJ/+eg0eMZG8dYCGJ MQJ/I0mXpYNKAh2gcp87JidFBbTtApOLm7dOIs0oc0BilaDKSPf8YN8L9TUsEZ5f SsY3iSFqUxVJ56AWd2QW26ONyeGYe/HwyoBgY0lWvoEGI6LbJyfCFDGBM42CRcTZ 2t7GlqGSm7IZNjPc4lJRzHhHHGmZFRJ9sMr7+nCmkLcE0XNIva4eqvgwebJalYv0 RdjQ3xZbOXepnVaG4E7TNdYoh3CErxu2JkIB5nQ9mXgXEHNLU9XSkP0GNTKZ7ZSl wuLqZXkhmRl3NdCPKwkS+Twz+CmOJ+I+GrjPNExWdXDsInZRc/xq7wt4lrGD5tmW tZugs4a4bDuejy86ewhp3xUgWY/0tmjq01q5Z1MFM7FFQWkM3PhOxNwVeb3VVPUC UZsHKoxZL9DDbUnhdtvSYkV9ZjZWLU2KAvvRn9CR0C0FoGQKFPWGNByRtvDgM8zb yuvFI4sZFARRwS7KY9wbZgcAcd0cOFvdhpYb2yNR2vbdBO+Qe6RMJpbswHRpWV2g WjXOzZwQW42lSuoBXTxoANfizhF8DxojmWBu5kbfVbe7sUHD8aI748AedfJl6nHW zE0QKb03++r0LT9SBT7VAGM38uZOYfzuuByNZr2zHJxAAjPfYkM= =NynC -----END PGP SIGNATURE----- --Sig_/xwCMdUTVlR+M93diBYDctVi--