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 AB281138247 for ; Wed, 13 Nov 2013 13:24:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A92FFE0BC7; Wed, 13 Nov 2013 13:23:55 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B4D24E0A04 for ; Wed, 13 Nov 2013 13:23:54 +0000 (UTC) Received: from [141.44.72.181] (fma181.math.uni-magdeburg.de [141.44.72.181]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tomka) by smtp.gentoo.org (Postfix) with ESMTPSA id 4777A33F2FE for ; Wed, 13 Nov 2013 13:23:53 +0000 (UTC) Message-ID: <52837DB7.90805@gentoo.org> Date: Wed, 13 Nov 2013 14:25:11 +0100 From: Thomas Kahle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 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 Subject: Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask References: <20131113123953.623ac06d@TOMWIJ-GENTOO> In-Reply-To: <20131113123953.623ac06d@TOMWIJ-GENTOO> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MveT6Ar4WdDM1B8fNLRAqnwHgtng8WgXf" X-Archives-Salt: 7c32be70-796b-45f6-a9bc-c1ecbd951488 X-Archives-Hash: 5fa1bc9b890d48e1d128906244a3afa3 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MveT6Ar4WdDM1B8fNLRAqnwHgtng8WgXf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, On 11/13/2013 12:39 PM, Tom Wijsman wrote: > On Wed, 13 Nov 2013 10:28:02 +0000 (UTC) > Martin Vaeth wrote: >=20 >> Hello. >> >> The new "features" use.stable.mask and package.use.stable.mask >> have turned maintaining systems with mixed ARCH and ~ARCH keywords >> into a nightmare: >=20 > They are considered unsupported by many; so, going down that path you > need to be acquainted with Portage enough to keep a consistent system. This argument has come up several times, but is it valid? For me and other people I know, the main reason to use Gentoo is the rolling release model and this implies that you can mix package versions as long as version dependencies are satisfied. When the dependency is "cat/package" then this should mean that it works with every version. If it does not, then the ebuild's dependencies should be updated. The handbook says nothing about "unsupported": http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3D3&chap=3D= 3 If "many" choose to change this policy, there is no reason anymore for me to use Gentoo. >> Similarly to the (fortunately dropped) concept of forcing >> useflags if certain packages are installed this forces a >> magic on the user which can hardly be managed since it is >> not clearly presented to the user but hidden in some profiles. >> >> As I understand, it tries to solve a "social" issue >> (that an ARCH user might set a USE-flag which eventually >> pulls in an ~ARCH package) on a technical level >> (by forcibly disabling the USE-flag for the user). >=20 > That's one approach, it might also be used when a package can be > stabilized but a certain of feature of the package cannot; eg. > USE=3D"minimal" could be broken on a certain package because it removed= a > bit too much, thus it could be stabilized with USE=3D"-minimal" forced.= >=20 > Anyhow, I think we should make sure to weight "why we need to have it" > against "how it bothers which users"; and not just focus on users alone= =2E >=20 > And other than that, are there alternatives? Something we can do better= ? We could consider reducing the feature set of portage and live with the "problems" that arise. When I started using Gentoo a package could simply not go stable until all dependencies for all USE flags were also stable. Masking USE flags was reserved to a short list of very special architecture depend special cases. [...] >> 2. Just a few days ago dev-lang/python-exec:2 became stable >> on amd64, but dev-python/python-exec:2 is still ~amd64. >> Just to be sure to not miss anything, I have put the latter >> into package.accept_keywords, and hell break loose: >=20 > Hell indeed breaks loose if you mix stable and unstable; but note that > this package had an accident, see the related news item for details. Do you mean stable and unstable in this case, or in general? [...] In general I share the sentiment. The complexity of using portage has increased a lot lately. Not only does it take long to find out why things suddenly go wrong after tree sync, also just the time until 'emerge -avUDN world' comes back with a proposal has grown to several minutes where it was few seconds when I started with Gentoo. There has been a lot of effort to make revdep-rebuild unessecary, but now that it is mostly implemented, I don't know if it was worth the price. I spend more time now just reconfiguring keywords to update the system than I spent back in the old days where revdep would just fix things. If the answer is, that I should not mix arch and ~arch, then I'll not use Gentoo anymore. Cheers, Thomas --=20 Thomas Kahle --MveT6Ar4WdDM1B8fNLRAqnwHgtng8WgXf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJSg323AAoJEDHSY8ey5xaRKRYH/3dSrLgWGG1ErCaAb4pus5rh 8DhDKaIXzF5mgcoo65vWwYW7pj3HfbRZ0yiAy+fBSsET+r/CbOnnX8LOprfiIrb7 Od1jsA5e7Q5+RTzArQsl7YmgrWlfd8+k6EZ/fmykBS/rKAnNKdeqmvWHHsNd1hWM 7UvTaKFZgeNHNVoCXN2GKW7d1QZigc+dmzChnoK0NDkMNMRmWx1EoBeGh46vv/vk eHBKglbIdd5jCmTQRCtrS42eD5DXKFYXjdo4ROShnHhYKC0vAEL+ATjYaQgbD31b ASflC6UFwaB6EW2nkcM2LX4hWVtLp6JzG8ARUZVVmaqAH6Qgvq7ZRgBq8Ezql4w= =aEZt -----END PGP SIGNATURE----- --MveT6Ar4WdDM1B8fNLRAqnwHgtng8WgXf--