public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Council meeting 19 April 2010
Date: Thu, 8 Apr 2010 15:14:52 +0100	[thread overview]
Message-ID: <20100408151452.0e01b1c1@snowmobile> (raw)
In-Reply-To: <4BBDE379.5010206@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

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.
> > 
> 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.

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?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2010-04-08 14:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-07  9:05 [gentoo-dev] Council meeting 19 April 2010 Ulrich Mueller
2010-04-07 14:23 ` Ben de Groot
2010-04-07 15:00   ` Denis Dupeyron
2010-04-07 17:14     ` Ben de Groot
2010-04-07 18:05       ` Denis Dupeyron
2010-04-07 18:22         ` Ben de Groot
2010-04-09 14:51         ` Dror Levin
2010-04-10 13:47           ` Petteri Räty
2010-04-07 21:02       ` Arun Raghavan
2010-04-07 21:45         ` Ben de Groot
2010-04-07 22:30     ` Richard Freeman
2010-04-08  1:27       ` Denis Dupeyron
2010-04-10 15:36     ` Petteri Räty
2010-04-08 11:41 ` Petteri Räty
2010-04-08 12:02 ` Brian Harring
2010-04-08 13:29   ` Ciaran McCreesh
2010-04-08 14:08     ` Patrick Lauer
2010-04-08 14:14       ` Ciaran McCreesh [this message]
2010-04-11  2:51   ` Brian Harring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100408151452.0e01b1c1@snowmobile \
    --to=ciaran.mccreesh@googlemail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox