From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 7E8D8139694 for ; Tue, 21 Mar 2017 09:17:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 522DD21C121; Tue, 21 Mar 2017 09:17:40 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 02C5321C104 for ; Tue, 21 Mar 2017 09:17:39 +0000 (UTC) Received: from localhost (dra13-4-78-234-166-189.fbx.proxad.net [78.234.166.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 2661633D3CE for ; Tue, 21 Mar 2017 09:17:37 +0000 (UTC) Date: Tue, 21 Mar 2017 10:17:32 +0100 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424 Message-ID: <20170321101732.752c546d@gentoo.org> In-Reply-To: <263d36db-1a1f-3570-951c-de3312756ed0@gentoo.org> References: <20170316093806.31977-1-mgorny@gentoo.org> <20170320083544.GZ24205@vapier> <22735.42420.523393.768428@a1i15.kph.uni-mainz.de> <20170320121937.7fc31770@gentoo.org> <22735.58203.928628.654288@a1i15.kph.uni-mainz.de> <20170320180140.66dbef67@gentoo.org> <22736.11456.309687.967555@a1i15.kph.uni-mainz.de> <89c42e1b-2599-2303-63f1-071b2d17bac1@gentoo.org> <263d36db-1a1f-3570-951c-de3312756ed0@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit X-Archives-Salt: bb2f8c0b-d689-4fac-9d6c-cd94a2e8eb9c X-Archives-Hash: 55d79291ce6eec7fd78d55b3131bb7b7 On Tue, 21 Mar 2017 09:43:37 +0100 Kristian Fiskerstrand wrote: > On 03/21/2017 09:28 AM, Joshua Kinard wrote: > > In general, the concept of code-sharing common blocks of logic > > between multiple ebuilds in a specific package directory that is > > not a top-level eclass is not entirely without merit. But the only > > way this idea can be realized in a suitable manner and be used by > > far more consumers than today's eblits are, is to either find and > > finish the old elibs GLEP or start one over from scratch, submit > > whatever needs submitting via patches to at least PMS and Portage, > > work through whatever processes are required for approval, and then > > deploy it in the next EAPI. > > > > If anyone is game for working something up or discussing further, > > let me know. > > I personally fail to see good reasons to have a separate approach for > this instead of putting it in the eclass framework. However this might > simply mean I'm missing something in the discussion. Technically there's 0 difference: you can very well name your elibs "${CAT}-${PN}-${VERSION}.eclass" and use the eclass mechanism. > Before restarting such a GLEP process; maybe a simple pros and cons > list of comparison of the future eblit use and existing eclass > structure could be helpful? (along with more description of the > differences) I'll skip the eblit vs nothing comparison. (up to discussion ofc) Pros for eblits vs the above eclasses: - Let eclass/, which is a toplevel directory, be a place for code useful to several packages, not a random dump of whatever people want to share between ebuilds of the same package (yes, I'm looking at you toolchain or apache2.eclass :) ). - Eblits being in package directory, repoman checks can be extended to look there. - Have a guarantee that eblits are specific to a single package and cannot "leak" to others by mistake: It greatly simplifies changing and updating them. - Eblits can be versionned, just the same as ebuilds or eclasses, but old versions have a life expectancy more of the order of an ebuild than that of an eclass. "Newborn" eblits would be expected to be much more frequent than eclasses but less frequent than ebuilds. - Eblits being per-package they'd obey to package rules, not eclass rules wrt additions, removals, api-preservation, etc. Cons: - Need a new, somewhat redundant, mechanism. - Can be done without new EAPI but is then restricted to src_* phases. - Very few consumers at the moment (though, considering the current crusade that's not really a relevant metric to me).