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 1Rg6nK-0003vB-Hi for garchives@archives.gentoo.org; Thu, 29 Dec 2011 03:36:42 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E647A21C084; Thu, 29 Dec 2011 03:36:32 +0000 (UTC) Received: from mail-iy0-f181.google.com (mail-iy0-f181.google.com [209.85.210.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 2C19221C021 for ; Thu, 29 Dec 2011 03:36:00 +0000 (UTC) Received: by iakk12 with SMTP id k12so24864163iak.40 for ; Wed, 28 Dec 2011 19:36:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=/7ZYwhNqNvqfPngckcOe5al4wP767J31q4UtJabdWuU=; b=S4buhLzSlYw7UTJqNwrU3dIkrDmfciZyMLQoKVTazrzOpunB8ag2K1jVGIdgxHfgwd BV7a38h0rSu1JUMjzywA+2S3tg/uUY6RqRgFqkXVI3+W8KhXJh91XRsQpn/a+STXtoUq BgufrG7ckW/QBvVbJ/uAVmIAZpjpo3bHqGCfI= Received: by 10.42.152.65 with SMTP id h1mr22037530icw.50.1325129760579; Wed, 28 Dec 2011 19:36:00 -0800 (PST) Received: from smtp.gmail.com:587 (74-95-192-101-SFBA.hfc.comcastbusiness.net. [74.95.192.101]) by mx.google.com with ESMTPS id l35sm109887235ibj.0.2011.12.28.19.35.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Dec 2011 19:35:59 -0800 (PST) Received: by smtp.gmail.com:587 (sSMTP sendmail emulation); Wed, 28 Dec 2011 19:36:01 -0800 Date: Wed, 28 Dec 2011 19:36:01 -0800 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds Message-ID: <20111229033601.GA18706@localhost> References: <4EFB6C24.1070307@gentoo.org> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 80383156-2b6e-46fc-b6e4-518cac12c53a X-Archives-Hash: 0d64deafbce778d1d92c793302ecc8b3 On Thu, Dec 29, 2011 at 02:37:07AM +0000, Francesco Riosa wrote: > 2011/12/28 Zac Medico : > > On 12/28/2011 05:12 AM, Francesco Riosa wrote: > >> Seem to me that append a time slice to the function, in the name or as > >> a parent function that call the underling function can solve most of > >> the versioning/deprecation problems > > > > I've overheard Arfrever discussing a similar approach in funtoo's irc > > channel, where the ebuild would set a variable prior to inherit if it > > wants to use a specific eclass API. For the python eclass, he's planning > > to have ebuilds set the PYTHON_ECLASS_API variable to use the new API. > > When the variable is unset, the eclass will default to the older API. > > There is a fundamental difference, with "timeslices" it's not the > ebuild that select the implementation but the point in time it's used, > or the user forcing a fake time. From what I've read Artfever approach > require changes in every ebuild and keeping old functions forever. On > the other hand it may be risky to change the preferred interface from > the eclass and not the ebuild. Respectfully, the proposals thus far (including python eclass bit) are going in the opposite direction of maintainability, simplicity, robustness. People have problems as is dealing w/ eclasses changing and their dependencies in external repositories not being updated; this complicates that issue and introduces the same potential into gentoo-x86 itself. That's not beneficial. Thing to keep in mind beyond the potential for confusion the proposals entail were they implemented, is the implementation itself. Timeslices? python eclass api versions (when people have problems figuring out the existing, *singular* version)? These things aren't going to be simple which means more than likely, they're going to break, and more than likely it's going to be a PITA to maintain it. Per the norm, I could be wrong, but reading these proposals, they really feel like they need to revisit the notion of maintainability/robustness as an actual full fledged implementation, beyond the (admittedly semi nifty) notion of versioned apis. My 2 cents, hopefully not at my usual offensive level- ~harring