From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KkCQm-0006Bo-B4 for garchives@archives.gentoo.org; Mon, 29 Sep 2008 06:40:28 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 85CD8E0796; Mon, 29 Sep 2008 06:40:27 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 3E754E0796 for ; Mon, 29 Sep 2008 06:40:27 +0000 (UTC) Received: from [192.168.22.10] (ip68-4-152-120.oc.oc.cox.net [68.4.152.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id B4EE5643DC for ; Mon, 29 Sep 2008 06:40:25 +0000 (UTC) Message-ID: <48E0784A.2040505@gentoo.org> Date: Sun, 28 Sep 2008 23:40:10 -0700 From: Zac Medico User-Agent: Thunderbird 2.0.0.17 (X11/20080914) 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] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets References: <48DECDFE.7010606@gentoo.org> <20080928213219.66a30341@snowmobile> <48DFEEB8.5040608@gentoo.org> <20080928220151.33656aca@snowmobile> <48E0011E.7040808@gentoo.org> <20080928232853.6540b31d@snowmobile> <48E00B9B.3060600@gentoo.org> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 735472f5-78b0-477f-bc6d-a8c2cc4ce919 X-Archives-Hash: 003c0ed83343ffded24ee7ea6c9b5d03 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Duncan wrote: > Zac Medico posted 48E00B9B.3060600@gentoo.org, > excerpted below, on Sun, 28 Sep 2008 15:56:27 -0700: > >> For example, `emerge kde-meta` would behave as as normal meta-package >> currently does, and `emerge @kde-meta` would reference the same package >> as a set and could thereby trigger different behavior which is >> appropriate for a set. > > Ahh... that's rather clearer now. Somehow I missed that bit before. > > However, it seems to me we'd have some of the same types of issues we've > previously discussed over the distinction between world and @world. It's > going to be virtually impossible to get some users to see the difference, > with the consequence being that they use the wrong reference (probably > skipping the @ as unnecessary typing) and end up with (to them) > completely unexpected behaviour. How long have we been drilling into > users' heads that they need to use --pretend (or --ask) --verbose to > check that what they intend is really what's going to happen? Yet I just > dealt with a case the other day where someone ended up with something > entirely (to them) unexpected, because they failed to preview what was > going to happen, first. I'm not suggesting that the ebuild and the package set necessarily need to have the same name. What I'm suggesting is that we use a configuration file, distributed with the ebuild repository, to map set names to ebuilds. This mapping would make the set name independent from the ebuild name. > Going out of our way to (effectively) make things even /more/ confusing > by deliberately creating set-packages that can be referred to as either, > with different behavior in each case, would seem to be the equivalent of > deliberately setting traps for those poor users. (Yes, they /should/ > know the difference and it's a PEBCAK if they don't/won't, but > unfortunately that PEBCAK is/can-safely-be-predicted-to-be rather > common...) > > So sure, we can institute it as suggested, damn the torpedos, but I > believe it's safely predictable that come a few months hence, after we've > dealt with our tenth person to end up screwing their system as a result, > we're going to rue the day... Never-the-less, it's not my decision. > I don't expect users to have much trouble with this concept, and they don't even have to use sets unless they want to make use of the additional features that sets provide. - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjgeEkACgkQ/ejvha5XGaOObQCghFkrhJiTVXAerwJXRbKJxk7R yKsAmgIWp1VAA2glNuQ+pa6U8OjnYszq =HzsM -----END PGP SIGNATURE-----