From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-project+bounces-2422-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 946C91381F3
for <garchives@archives.gentoo.org>; Wed, 10 Apr 2013 20:22:36 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 17F38E0AA3;
Wed, 10 Apr 2013 20:22:36 +0000 (UTC)
Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 75C5AE0AA2
for <gentoo-project@lists.gentoo.org>; Wed, 10 Apr 2013 20:22:30 +0000 (UTC)
Received: by mail-vb0-f49.google.com with SMTP id 11so722865vbf.36
for <gentoo-project@lists.gentoo.org>; Wed, 10 Apr 2013 13:22:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:x-received:sender:in-reply-to:references:date
:x-google-sender-auth:message-id:subject:from:to:content-type;
bh=emXvOYDqoCflgHoQ3LMlUO2NcgLwOvMtGqOPOeY2ipk=;
b=uSSqZK9OSpa5CtGvHcuugDrlRf6z0/sEgOpPLX20rX45LffFOLWsGOBiHq9VR0bM0R
PQ3viWRufNUhSr2HgM5DQbqHnlwK5t3k6IYAzmIn5Z643KniXHL9bozWaCUCdMpwWuyX
hHokyJUyx/dMtpxQz/2ohjevW1ZnsJZIAa11MMvP5B27xwHzLz4Fbiy97EqrMtbWdhbX
EByUb2rOFXHMFJfDzV8k0LvBvferyhK5VGcTlheBJ+/x/5+hIYWnUBHRQADzEzq4eA2y
ghwZPwtNZBXEKvvz4GD5f4yqdEVTdS7kVIh7ernQeVPYny7RXwomrc17mnau6ejjzMcM
fqfg==
Precedence: bulk
List-Post: <mailto:gentoo-project@lists.gentoo.org>
List-Help: <mailto:gentoo-project+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-project+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-project+subscribe@lists.gentoo.org>
List-Id: Gentoo Project discussion list <gentoo-project.gentoo.org>
X-BeenThere: gentoo-project@lists.gentoo.org
Reply-To: gentoo-project@lists.gentoo.org
MIME-Version: 1.0
X-Received: by 10.220.77.138 with SMTP id g10mr2784485vck.69.1365625349628;
Wed, 10 Apr 2013 13:22:29 -0700 (PDT)
Sender: freemanrich@gmail.com
Received: by 10.52.168.4 with HTTP; Wed, 10 Apr 2013 13:22:29 -0700 (PDT)
In-Reply-To: <201304101530.07375.vapier@gentoo.org>
References: <20817.55135.354752.397336@a1i15.kph.uni-mainz.de>
<20130408232028.56cdad67@caribou.gateway.2wire.net>
<20130409181233.GA10952@comet.hsd1.mn.comcast.net>
<201304101530.07375.vapier@gentoo.org>
Date: Wed, 10 Apr 2013 16:22:29 -0400
X-Google-Sender-Auth: skZ8NtEtP2Bx5DNaoggodcf0Drw
Message-ID: <CAGfcS_mNh+zzaCP0psNeAULp6_j17iseVy5cFLWtdJF+EonjNw@mail.gmail.com>
Subject: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-project@lists.gentoo.org
Content-Type: text/plain; charset=ISO-8859-1
X-Archives-Salt: b910f395-f5d3-430a-aa66-ee899d3a0e63
X-Archives-Hash: 992978e069c7f203cf517c4a14575226
On Wed, Apr 10, 2013 at 3:30 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> we can could create a "toolchain-stable.eclass". whenever we stabilize a new
> version, we copy the current toolchain.eclass to toolchain-stable.eclass and
> change the newly stabilized ebuild to inherit that instead.
>
> for all other versions (unstable, and older stable), we have them use the
> toolchain.eclass.
That sounds slightly better than how a few infamous libs handle
SONAMEs and ABIs.
I think the real problem is that we're defining functions without
clearly defining the inputs and outputs. The input is essentially a
tarball or directory tree that is expected to be in a fairly
particular format, but upstream does not commit to keeping these
formats across versions.
This is like defining a function in an eclass that takes two integers
as parameters, and then in the next eclass revision having it take two
strings. That is obviously going to create a mess unless you
carefully modify all the references to that function on every bump.
Heaven forbid anybody with an overlay wants to use it.
toolchain.eclass is only used by gcc, kgcc64, and gcc-apple. Would it
just make more sense to inline it? That makes all these issues go
away - each version has its own independent quality process and there
is no risk of changes breaking things across versions.
Rich