From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 946C91381F3 for ; 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 ; Wed, 10 Apr 2013 20:22:30 +0000 (UTC) Received: by mail-vb0-f49.google.com with SMTP id 11so722865vbf.36 for ; 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: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list 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: Subject: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09 From: Rich Freeman 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 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