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-32899-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1Kk4lE-0006o5-PT
for garchives@archives.gentoo.org; Sun, 28 Sep 2008 22:29:05 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 4EB2FE04AE;
Sun, 28 Sep 2008 22:29:04 +0000 (UTC)
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168])
by pigeon.gentoo.org (Postfix) with ESMTP id EEEEFE04AE
for <gentoo-dev@lists.gentoo.org>; Sun, 28 Sep 2008 22:29:03 +0000 (UTC)
Received: by ug-out-1314.google.com with SMTP id m2so247395uge.39
for <gentoo-dev@lists.gentoo.org>; Sun, 28 Sep 2008 15:29:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlemail.com; s=gamma;
h=domainkey-signature:received:received:date:from:to:subject
:message-id:in-reply-to:references:x-mailer:mime-version
:content-type;
bh=lphhCq5KYNPHhPF8/i1YTX6xSaQw431LAIjUVq1rt7I=;
b=iRacW2904xVz/7zF8Ncpe9KBwyMS4zi19TzP7uwB4niy0NsxOJe4bRn15AAcLG7J/C
thTOst2P3N0inHUc/8Tkoh8M7A12HMqmwURL7Mf60wgc5kGJZoqCcsgowq5zKKCNi8ap
TRGSocRKYnxpgnz5t94iQr0BivQfKOaMzJGqk=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=googlemail.com; s=gamma;
h=date:from:to:subject:message-id:in-reply-to:references:x-mailer
:mime-version:content-type;
b=bfOrCRO3WmZ1AIzAsxNoKRtPIdjyQrze4isZ2CeHd8Fq50BWEft8rkXtm7l1vuxO6C
JbtGi1xeqHczeK55eY74k5OfdcmNP9x4YhA97zbX6Fe6HM2M3Fa6wJFlqdefG38PDINz
1H9UZFZDvs1oyl5MBXr/x5V/ysw8QmwnbD91M=
Received: by 10.210.124.15 with SMTP id w15mr5254551ebc.115.1222640941641;
Sun, 28 Sep 2008 15:29:01 -0700 (PDT)
Received: from snowmobile (92-235-187-79.cable.ubr18.edin.blueyonder.co.uk [92.235.187.79])
by mx.google.com with ESMTPS id m5sm2791853gve.3.2008.09.28.15.29.00
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Sun, 28 Sep 2008 15:29:01 -0700 (PDT)
Date: Sun, 28 Sep 2008 23:28:53 +0100
From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should
behave like package sets
Message-ID: <20080928232853.6540b31d@snowmobile>
In-Reply-To: <48E0011E.7040808@gentoo.org>
References: <48DECDFE.7010606@gentoo.org>
<20080928213219.66a30341@snowmobile>
<48DFEEB8.5040608@gentoo.org>
<20080928220151.33656aca@snowmobile>
<48E0011E.7040808@gentoo.org>
X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i686-pc-linux-gnu)
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: multipart/signed; boundary="Sig_/s7uu8oIXIAyrv/q2BlzTvC4";
protocol="application/pgp-signature"; micalg=PGP-SHA1
X-Archives-Salt: 2f79428e-773a-4920-abef-3920cad69744
X-Archives-Hash: c0a76cfbb7914a0bca2907fe86e540b1
--Sig_/s7uu8oIXIAyrv/q2BlzTvC4
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
On Sun, 28 Sep 2008 15:11:42 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> > GLEP 37 effectively abolishes virtuals. It doesn't try to overload
> > new behaviour onto packages.
>=20
> Well, PROPERTIES=3Dset doesn't necessarily need overload new behavior
> onto packages any more that virtual ebuilds do. If set-property
> ebuilds are mapped into set space then the overloaded behavior will
> come from them being referenced as sets, which won't overload their
> ebuild behavior since they can simply behave like existing
> meta-packages already do.
Ok, so say we have cat/foo-1:
PROPERTIES=3D""
DEPEND=3D"cat/one cat/two cat/three"
RDEPEND=3D"cat/two cat/four"
and cat/foo-2:
PROPERTIES=3D"set"
DEPEND=3D"cat/one cat/two cat/three"
RDEPEND=3D"cat/two cat/four"
Then what does this do in package.use?
cat/foo monkey
What does this do in package.mask?
cat/foo
What about this?
>=3Dcat/foo-2
What about this?
<cat/foo-2
What does this do?
emerge -uDpv cat/foo
What about this?
emerge -uDpv \>=3Dcat/foo-2
What about this?
emerge -uDpv \<cat/foo-2
Now let's introduce cat/bar-1:
DEPEND=3D"cat/foo"
and cat/bar-2:
DEPEND=3D"=3Dcat/foo-1"
What does this do?
emerge -e cat/bar
What about:
emerge -e =3Dcat/bar-1
And how is this anything other than highly weird?
Here's an alternate proposal: Repositories can ship sets via files in
sets/*.conf. The format is as described in [1]. In configuration files,
operations applied to a set are applied to anything matching any spec
listed in that set (or any set that set contains, and so on). On the
command line, sets and non-sets cannot be mixed, and multiple sets
cannot be specified.
[1]: http://paludis.pioto.org/configuration/sets.html
--=20
Ciaran McCreesh
--Sig_/s7uu8oIXIAyrv/q2BlzTvC4
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkjgBScACgkQ96zL6DUtXhGVZQCePFe4T8MZIz4B44PYMHo5pgzi
b1gAnil+jzy66Emezg/H8HjsLJ6RMwRo
=YaNI
-----END PGP SIGNATURE-----
--Sig_/s7uu8oIXIAyrv/q2BlzTvC4--