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-32923-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1KkPiO-0002Ue-UX
for garchives@archives.gentoo.org; Mon, 29 Sep 2008 20:51:33 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id CCDAAE0469;
Mon, 29 Sep 2008 20:51:31 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id 85261E0469
for <gentoo-dev@lists.gentoo.org>; Mon, 29 Sep 2008 20:51:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp.gentoo.org (Postfix) with ESMTP id 6A46A64DD2
for <gentoo-dev@lists.gentoo.org>; Mon, 29 Sep 2008 20:51:30 +0000 (UTC)
X-Virus-Scanned: amavisd-new at gentoo.org
X-Spam-Score: -1.471
X-Spam-Level:
X-Spam-Status: No, score=-1.471 required=5.5 tests=[AWL=0.061,
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 PNx8oSOtoH11 for <gentoo-dev@lists.gentoo.org>;
Mon, 29 Sep 2008 20:51:24 +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 647786401A
for <gentoo-dev@gentoo.org>; Mon, 29 Sep 2008 20:51:23 +0000 (UTC)
Received: from list by ciao.gmane.org with local (Exim 4.43)
id 1KkPi9-0000iM-RI
for gentoo-dev@gentoo.org; Mon, 29 Sep 2008 20:51:17 +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:51:17 +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:51:17 +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: Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets
Date: Mon, 29 Sep 2008 21:42:21 +0100
Message-ID: <gbrf3u$7ps$1@ger.gmane.org>
References: <48DECDFE.7010606@gentoo.org> <48E06FE2.3010403@gentoo.org> <48E076A3.5060401@gentoo.org> <gbrc69$ts8$1@ger.gmane.org> <48E13A75.4010800@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: b19c94a3-6451-47eb-8e02-56eb64cdd04b
X-Archives-Hash: 94e01067fc24af79addf6506d544a038
Zac Medico wrote:
> Steve Long wrote:
>> Zac Medico wrote:
>>> R=E9mi Cardona wrote:
>>>> As one of the maintainers of the gnome-base/gnome meta, I fail to se=
e
>>>> 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) ?
>>>>
>>> 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.
>>=20
>> Makes sense to me, though not sure you need the mapping file. I'm
>> perfectly 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, and then removing some of the packages, the user could contin=
ue
>> to reference the set for upgrade, without portage reinstalling those?
>=20
> That would be a set subtraction operation, so the user would use a
> configuration file to configure the set so that certain unwanted
> atoms are automatically subtracted out. Alternatively, we could
> implement a syntax extension for "optional atoms" that are only
> pulled into the dependency graph if they happen to be installed already=
.
>=20
It would be nice to address it; wrt people installing a meta which will
define a set, it'd make it easier to maintain (a box) if the set syntax
referred to whatever was installed, whereas emerging the package would
install all its deps as a standard virtual does (in the default setting.)
Integrating seems like a good idea, wrt to the USE settings you discussed=
in
the other thread. There is already a framework in place to model all that=
,
and more, so might as well use it. (I'd vote for allowing as much
flexibility as the ebuild author wants to specify.)