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 <gentoo-dev+bounces-32921-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1KkOwC-0005PA-6f
for garchives@archives.gentoo.org; Mon, 29 Sep 2008 20:01:44 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 63A49E0741;
Mon, 29 Sep 2008 20:01:42 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id 3B0D2E0741
for <gentoo-dev@lists.gentoo.org>; Mon, 29 Sep 2008 20:01:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp.gentoo.org (Postfix) with ESMTP id 900B964DA3
for <gentoo-dev@lists.gentoo.org>; Mon, 29 Sep 2008 20:01:40 +0000 (UTC)
X-Virus-Scanned: amavisd-new at gentoo.org
X-Spam-Score: -1.468
X-Spam-Level:
X-Spam-Status: No, score=-1.468 required=5.5 tests=[AWL=0.064,
BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067]
Received: from smtp.gentoo.org ([127.0.0.1])
by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id aQ5nxIxVxNRc for <gentoo-dev@lists.gentoo.org>;
Mon, 29 Sep 2008 20:01:34 +0000 (UTC)
Received: from ciao.gmane.org (main.gmane.org [80.91.229.2])
(using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested)
by smtp.gentoo.org (Postfix) with ESMTP id DDCA764774
for <gentoo-dev@gentoo.org>; Mon, 29 Sep 2008 20:01:32 +0000 (UTC)
Received: from list by ciao.gmane.org with local (Exim 4.43)
id 1KkOvr-00079J-MD
for gentoo-dev@gentoo.org; Mon, 29 Sep 2008 20:01:23 +0000
Received: from 91.85.135.147 ([91.85.135.147])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-dev@gentoo.org>; Mon, 29 Sep 2008 20:01:23 +0000
Received: from slong by 91.85.135.147 with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-dev@gentoo.org>; Mon, 29 Sep 2008 20:01:23 +0000
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-dev@lists.gentoo.org
From: Steve Long <slong@rathaus.eclipse.co.uk>
Subject: [gentoo-dev] Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
Date: Mon, 29 Sep 2008 20:52:24 +0100
Message-ID: <gbrc69$ts8$1@ger.gmane.org>
References: <48DECDFE.7010606@gentoo.org> <48E06FE2.3010403@gentoo.org> <48E076A3.5060401@gentoo.org>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: 91.85.135.147
User-Agent: KNode/0.10.9
Sender: news <news@ger.gmane.org>
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: 959ba92c-e0c9-4722-a707-2449874ceca5
X-Archives-Hash: d166e0ed67519148130a4a4bc3e16e03
Zac Medico wrote:
> R=E9mi Cardona wrote:
>> Zac Medico a =E9crit :
>>> Please consider a PROPERTIES=3Dset value that allows an ebuild to
>>> indicate that it should behave like a package set when selected on
>>> the command line. This is behavior is somewhat difficult to describe
>>> in words but the following example should be sufficient to convey
>>> the general idea.
>>=20
>> As one of the maintainers of the gnome-base/gnome meta, I fail to see
>> the usefulness of such a change. We have yet to ask users to rebuild
>> "gnome" completely. Do you have any specific use cases (maybe coming
>> from the KDE herd, since you used the kde meta as an example) ?
>>=20
>> The one thing that bothers me about this is consistency: if, say, xfce
>> (let's change ;) ) decides to use PROPERTIES=3Dset, users will have a
>> different experience with their ebuild than with the other metas we
>> currently ship.
>>
Only when they consciously use the set syntax, surely?
=20
>> All in all, I'm not really against such a change, however I really fai=
l
>> to see the win for everyone, end-users included.
>=20
> Over the course of the discussion I've revised the idea so that it
> essentially represents a way to define a package set, without any
> changes to existing behavior. What will change is that we will have
> a new way to define package sets, based on ebuilds.
Makes sense to me, though not sure you need the mapping file. I'm perfect=
ly
happy about emerge -uDN @kde-meta say, updating all kde-meta packages I
might have installed; I take it that after emerge kde-meta to install, an=
d
then removing some of the packages, the user could continue to reference
the set for upgrade, without portage reinstalling those?