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 ECE761381F3 for ; Tue, 9 Apr 2013 08:13:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 67E51E0A9D; Tue, 9 Apr 2013 08:13:07 +0000 (UTC) Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C1A76E0A99 for ; Tue, 9 Apr 2013 08:13:06 +0000 (UTC) Received: by mail-vb0-f53.google.com with SMTP id i3so4429654vbh.40 for ; Tue, 09 Apr 2013 01:13:06 -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:cc:content-type :content-transfer-encoding; bh=plkKEXwF0AoZinUCw06RxMjnR+Gu+6E+XgxjwbjP6Ks=; b=vXW5jz8emVGs5u9atTCKnxvWa87qynHSUg6QLuAu5h6rB+ct9HCSziEJSHYXaATWgl RnkAPxzsRoKtF2wWwJjuNbI1ZpwmkOUolHHYGwggaG2uUelgcnVUAtTb8TanzHPiEyyr VarZRFBAeGd/iyKqcEUoA/ncjtfIyHqqnIkZqiSQm7N1m8TU4fUPyeuZoPk7mFb8QbuX WAgIZmnxlWq0uU8sFLZ4rWCihaEYJxMfzhA6JyIx9FaaOkjq0oraKnZjJJHB8degW2se 95ErAogq/6LaQqZDX4XFhjdxIRilSQOgozg4g9vLavlX6HDpQ0ppyzbjOcgvqPFriEaX z3kg== 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.154.66 with SMTP id n2mr1087701vcw.40.1365495185899; Tue, 09 Apr 2013 01:13:05 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.101.225 with HTTP; Tue, 9 Apr 2013 01:13:05 -0700 (PDT) In-Reply-To: <20130409075747.24cc17d3@pomiocik.lan> References: <20817.55135.354752.397336@a1i15.kph.uni-mainz.de> <201304070037.28554.dilfridge@gentoo.org> <20130406200511.01d4c0e9@caribou.gateway.2wire.net> <201304071409.03862.dilfridge@gentoo.org> <20130408232028.56cdad67@caribou.gateway.2wire.net> <20130409075747.24cc17d3@pomiocik.lan> Date: Tue, 9 Apr 2013 04:13:05 -0400 X-Google-Sender-Auth: bx8a18IE_1q6qqw3gUKpC4mkuCQ 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 Cc: dirtyepic@gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 24df206b-1b5c-4851-8144-c871d699f1df X-Archives-Hash: 6e11ab09f8ef1f0248f6bc78e2c1a331 On Tue, Apr 9, 2013 at 1:57 AM, Micha=C5=82 G=C3=B3rny = wrote: > On Mon, 8 Apr 2013 23:20:28 -0600 > Ryan Hill wrote: > >> If someone else wants to try and improve the situation, please feel free= . > > Just to be sure -- would you be ok if we tried to inline some > of the eclass code into the ebuilds (future versions/revbumps)? Honestly, when you're talking about small numbers of packages I think this is the only thing which is sustainable. Eclasses should perform generic functions which have well-defined inputs and outputs which are broadly applicable. When you start building them for small groups of packages you start to run into situations like this. If your ebuilds basically just contain KEYWORDS and little more then the eclasses are doing too much for sure. I can see the need for cases like python/perl/etc eclasses when you have a large number of packages which need similar logic, but if the inputs/outputs of the functions change then the functions should change names. So, rather than overriding src_prepare and then doing a bunch of logic to figure out which of 12 different upstream packaging approaches was in use it should just have 12 different functions and the ebuild should call the right one from its own src_prepare. Then you can actually deprecate functions that are no longer needed, and not change functions that are being used in stable (or if you change them you're less likely to break them because each function only operates on a well-defined set of inputs and outputs). Bottom line is that automagic eclasses can sometimes be as bad as automagic build systems, for most of the same reasons. And that isn't even getting into the fact that we don't really have any mechanism for getting rid of eclasses. All that crufty code just collects. (I'm sure I missed a few good uses for eclasses above, but I'd still tend to say that if an eclass function is accepting data in many different formats it is probably doing too much.) Rich