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 1SiTf0-0007kw-NN for garchives@archives.gentoo.org; Sat, 23 Jun 2012 16:58:17 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E684721C0A3; Sat, 23 Jun 2012 16:57:56 +0000 (UTC) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by pigeon.gentoo.org (Postfix) with ESMTP id 8298421C09F for ; Sat, 23 Jun 2012 16:57:17 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so1542594wib.4 for ; Sat, 23 Jun 2012 09:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=TzKfXoe0fB9r1puNk+edbkx2+Y86NQYIMg5W0O2u0b0=; b=ZywaHAL6STfOZbE+C4RPJ2IsH3RsyFsT3+yvppwKj6h5oDwKKZq92lNj4XQfJVfhpk aHBpkWG9e0oLJMT1bifVLyOdZFfcsQ+64RE5lQpO4zH342JhEr2FcICRIyB9Bsqo9AwB Tms4h0ViFuh/hSFYA64GkLuQ8kI3G+gftHZsDZP2QTIBuPm2XvVSFUzfVcw61wb9d4ws ydeVn6fA98AxACQWfqkbr2zTK4qSV9xklhs21opoYmx7AreYb6g4IwjWoDIWVuD85vV0 41lKh0jD2jLddYf72+HYJMG1hbeMVtob2JoS2N+xs8vQ31dK/zeaVcuHu8iu0U5dAheM i7Zg== Received: by 10.216.228.232 with SMTP id f82mr3267129weq.211.1340470636622; Sat, 23 Jun 2012 09:57:16 -0700 (PDT) Received: from localhost (cpc13-broo7-2-0-cust130.14-2.cable.virginmedia.com. [82.9.16.131]) by mx.google.com with ESMTPS id k8sm11740681wia.6.2012.06.23.09.57.15 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Jun 2012 09:57:16 -0700 (PDT) Date: Sat, 23 Jun 2012 17:53:24 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: PROPERTIES=funky-slots Message-ID: <20120623175324.038ca62e@googlemail.com> In-Reply-To: <4FE5F31E.80608@gentoo.org> References: <20120623142143.631d7ebf@googlemail.com> <4FE5EB23.5040600@gentoo.org> <20120623171704.4f24cba6@googlemail.com> <4FE5F31E.80608@gentoo.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; 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-SHA1; boundary="Sig_/ToNEU7HcX9ElKutoDJdwgd3"; protocol="application/pgp-signature" X-Archives-Salt: 5b84346b-4333-42fc-93a6-0e41da31908a X-Archives-Hash: 4ecd09e992898c89aa0c68cece96c45c --Sig_/ToNEU7HcX9ElKutoDJdwgd3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 23 Jun 2012 18:47:26 +0200 Justin wrote: > On 23.06.2012 18:17, Ciaran McCreesh wrote: > > On Sat, 23 Jun 2012 18:13:23 +0200 > > Justin wrote: > >> Did you read what you wrote and thought about what you request from > >> others? Probably you better should. > >=20 > > Uh huh, and I think we all know there's a huge difference between > > knowing what versions and slots are and knowing what "a multilib" > > is. > >=20 >=20 > Might be right, but that doesn't allow you to break your own rules. > Plus I still don't get the problem of using SLOTS in the way they are > used now. "My own rules" are that enough material is presented that the relevant people understand it. If you look at simple proposals like usex, silent rules or EBUILD_PHASE_FUNC, you'll see quite clearly that we ask for very little in the way of text in cases where the change is easily understood. > And I can't find this out by simply googling. In contrast, an > explanation of multilib in context of linux distribution and more > specific gentoo can be found easily. Oh really? I was under the impression that there wasn't even general agreement upon whether or not multilib applied to "C" or to "C, and Python, and things like it". > Stop acting in this arrogant way you are doing right now. Come on. Submitting a simple proposal with at least as much detail as was provided for other, equally simple proposals is "arrogant" now? > > That's covered in the devmanual and in the user documentation, so > > there's no need to repeat it here. >=20 > Ever heard about references. They are good, if you don't like to > repeat what is written, but which are necessary context to understand > what you are writing. You should use them for the sake of > understanding, if you are to lazy to write it out again. Please take a look at the proposal for EBUILD_PHASE_FUNC, and say where it references what "phase functions" are, or the proposal for usex and say where it references what "use flags" are, or the proposal for silent rules where it references what "econf" is. > >> To me, it doesn't solve the root cause, but actually I can't judge > >> this, because I am missing a description of what is really going > >> wrong. > >=20 > > As I've already said, this isn't about solving the root cause. It's > > about reducing the impact of damage that's already been done until > > the root cause is solved properly. >=20 > My clear vote is No. We shouldn't implement anything which allows bad > coding anywhere, just for the sake of having it "solved" now. The bad coding has already happened. Are you volunteering to revert the Ruby virtuals? --=20 Ciaran McCreesh --Sig_/ToNEU7HcX9ElKutoDJdwgd3 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk/l9IcACgkQ96zL6DUtXhFHHACg2k7yMcmEUnLSwPewOHnHMRJG EmYAn14dbGb/TDizDFesIOWsmxEOpbNZ =+eNw -----END PGP SIGNATURE----- --Sig_/ToNEU7HcX9ElKutoDJdwgd3--