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 ) id 1NzsNv-0002jz-2H for garchives@archives.gentoo.org; Thu, 08 Apr 2010 14:07:07 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 37376E09B5; Thu, 8 Apr 2010 14:07:05 +0000 (UTC) Received: from dev.gentooexperimental.org (unknown [91.191.147.225]) by pigeon.gentoo.org (Postfix) with ESMTP id D39DCE0904 for ; Thu, 8 Apr 2010 14:06:44 +0000 (UTC) Received: from [192.168.2.100] (ip-109-85-108-240.web.vodafone.de [109.85.108.240]) by dev.gentooexperimental.org (Postfix) with ESMTPA id 30A01602DC for ; Thu, 8 Apr 2010 14:06:42 +0000 (Local time zone must be set--see zic manual page) Message-ID: <4BBDE379.5010206@gentoo.org> Date: Thu, 08 Apr 2010 16:08:57 +0200 From: Patrick Lauer User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100326 Thunderbird/3.0.3 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] Council meeting 19 April 2010 References: <19388.19166.779165.480708@a1i15.kph.uni-mainz.de> <20100408120225.GG10006@hrair> <20100408142931.4a22a682@snowmobile> In-Reply-To: <20100408142931.4a22a682@snowmobile> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 7bcca8dd-0a9b-4095-b143-652df34b88d0 X-Archives-Hash: 72587f5218284043a7521f14c196f74f On 04/08/10 15:29, Ciaran McCreesh wrote: > On Thu, 8 Apr 2010 05:02:25 -0700 > Brian Harring wrote: >> 4) if there are questions re: use cycle breaking or other bits, feel >> free to ask prior please- council meeting times unfortunately right >> now intersect badly with my paying work so it's hard to be online to >> answer questions during the meeting (that said per the norm I'll try). > > 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. > That would violate the Entscheidungsproblem. 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. Abandoning the idea as a whole just because there may be a corner case that isn't as easy appears quite silly to me. Brian's proposal is the only one I've seen that is deterministic and sane, so I think we should figure out if we can improve it instead of giving up at the first bump in the road.