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 <gentoo-dev+bounces-40641-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1NzsWB-0003GN-Fk
for garchives@archives.gentoo.org; Thu, 08 Apr 2010 14:15:40 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id D922BE07E8;
Thu, 8 Apr 2010 14:15:35 +0000 (UTC)
Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223])
by pigeon.gentoo.org (Postfix) with ESMTP id 8F7EBE0916
for <gentoo-dev@lists.gentoo.org>; Thu, 8 Apr 2010 14:15:17 +0000 (UTC)
Received: by bwz23 with SMTP id 23so1897488bwz.26
for <gentoo-dev@lists.gentoo.org>; Thu, 08 Apr 2010 07:15:17 -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=9RiMCbGswsGF1yEDkJRxotb54NVHW90iGzujw57S7Qc=;
b=FGF5k+Fg0FOL7htyKKZlAmNWJ45j3mdjxqr01/tQLRk7GtG94zd9ME2zi4WvmAdQ9a
NqN8vFyPxLmgW7U9K1zSDMvLpfMZHq8+i8erNXQCCkdpkg3DNe0nj6uxMBBpFTaRpkWf
pdvh2ZEMaiB1Kw3WFxWEu4Aveu3ZDwUm1AXA0=
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=dh4OP1Qdup+XcRQwRmMnabTQO0dG78PtOOlKi39hsk6wWZ5SffuS0cm2bEVkkXf5dN
BBFRDGu0L9u4x4b/H2zKQJVZScf0poI5XqLNlDTCxDKWeP7zLDKE1kFdlwClW9C4Ql0f
vKKND4HZD2dc6ViyzQHc2G6jcOtoVAND/y8iw=
Received: by 10.204.136.142 with SMTP id r14mr239687bkt.8.1270736116828;
Thu, 08 Apr 2010 07:15:16 -0700 (PDT)
Received: from snowmobile ([92.24.206.178])
by mx.google.com with ESMTPS id a11sm888830bkc.15.2010.04.08.07.14.58
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Thu, 08 Apr 2010 07:14:58 -0700 (PDT)
Date: Thu, 8 Apr 2010 15:14:52 +0100
From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Council meeting 19 April 2010
Message-ID: <20100408151452.0e01b1c1@snowmobile>
In-Reply-To: <4BBDE379.5010206@gentoo.org>
References: <19388.19166.779165.480708@a1i15.kph.uni-mainz.de>
<20100408120225.GG10006@hrair>
<20100408142931.4a22a682@snowmobile>
<4BBDE379.5010206@gentoo.org>
X-Mailer: Claws Mail 3.7.4 (GTK+ 2.18.5; 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; micalg=PGP-SHA1;
boundary="Sig_/iX1xn62km3GPHgqsE92o1Ey"; protocol="application/pgp-signature"
X-Archives-Salt: 02198874-8776-4873-b235-6c9361f16f7a
X-Archives-Hash: edc775db687c4aae1020a20ce7de71b2
--Sig_/iX1xn62km3GPHgqsE92o1Ey
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
On Thu, 08 Apr 2010 16:08:57 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> > Please detail your cycle breaking algorithm that works in such a way
> > that it's guaranteed not to toggle flags that will break a system,
> > but that does not require any changes to be made to ebuilds etc
> > telling the package manager what those flags are.
> >=20
> That would violate the Entscheidungsproblem.
>=20
> But why would you make the cycle breaking depend on an oracle? Once we
> have the method in place we can find the two special cases and think
> of ways to fix them.
The problem is, the special cases where it goes horribly wrong aren't
rare. As soon as you start looking for cycles, you find flags like
'build', 'bootstrap' and 'acl'.
> Abandoning the idea as a whole just because there may be a corner
> case that isn't as easy appears quite silly to me.
I'm not after abandoning the idea. I'm after doing it properly, and
doing it properly starts by handling the problematic cases rather than
pretending they don't exist.
We've already seen repeatedly what goes wrong when you start with the
assumption "it'll probably work" and then pile on special exceptions
every time someone gets screwed over by something you didn't think of.
Why don't we go with "we'll only do it for things where we know it'll
work" instead this time?
--=20
Ciaran McCreesh
--Sig_/iX1xn62km3GPHgqsE92o1Ey
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEARECAAYFAku95N4ACgkQ96zL6DUtXhEnzQCg3ULA6N8LSKQtx6XvEl1rxA1Z
ZIEAnjMCl/In9i4A+TL+DH+gIbJi0WIm
=c9jL
-----END PGP SIGNATURE-----
--Sig_/iX1xn62km3GPHgqsE92o1Ey--