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 D6BF7139694 for ; Tue, 21 Mar 2017 21:54:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2401F21C1D8; Tue, 21 Mar 2017 21:54:44 +0000 (UTC) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (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 BFC0621C18E for ; Tue, 21 Mar 2017 21:54:43 +0000 (UTC) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-08v.sys.comcast.net with SMTP id qRidc8OwWoI4JqRjlcN8Tw; Tue, 21 Mar 2017 21:54:41 +0000 Received: from [192.168.1.13] ([73.201.78.97]) by resomta-po-15v.sys.comcast.net with SMTP id qRjjcIj5mHYoLqRjkcph1y; Tue, 21 Mar 2017 21:54:41 +0000 Subject: Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424 To: gentoo-dev@lists.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> From: Joshua Kinard Message-ID: <6caf3cb4-10ce-35c8-0045-5b497af20ef0@gentoo.org> Date: Tue, 21 Mar 2017 17:54:30 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 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 In-Reply-To: <263d36db-1a1f-3570-951c-de3312756ed0@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNSzlXUNrtuKf/Ld07UzgCeBfvjILKdT1drG5S1iwWZtJ/woO/K67N4iG+9JNLgwQczF+zxhnTsd+spXEdOl4T36XmzzlyAymBPanbOVyMx8rhKmoiTD UoIL4oomrHo5HjrXVJ0N98KLHTEUQXwqqXU/hiH6b+aGdXp1bvzhEPRXjah5XJvF4x96gw2VTbrX5g== X-Archives-Salt: b4b9cf25-45fc-4a9a-9723-7766c72da793 X-Archives-Hash: 272f8f5a41d1de0e4de439c3ab40f105 On 03/21/2017 04:43, 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. > > 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) Well, maybe it's a sign of my age and tenure, but I always thought one should be conservative in the definition of new eclasses. I may be wrong, but back in the old days, to define a new toplevel eclass, I believe one had to demonstrate that a number of different packages all had common ebuild logic that could all merged into a single eclass. Kinda like what we do now with new global USE flags. So throwing package-specific eclasses into the toplevel eclass directory seems to run against this. Additionally, repoman does not validate the logic in eclasses currently (a long-time issue), which can lead to code rot of such package-specific common code. That said, I'm not wedded to the current implementation of eblits as they exist, and IMHO, I do agree in principle with QA that any such feature like that needs to be defined in PMS and employed by the package manager in some capacity. It is certainly doable right now with an eclass (I even have an example eblit.eclass that demos this), but it would be better to leverage existing loading and sourcing logic within the package managers for such a capability, which means changing them and updating PMS, which effectively means a new EAPI. How we go about implementing this idea, or whether we even bother to do so, is what needs to be discussed. I certainly have some ideas, but I've largely isolated myself to the MIPS world the last few years and my ideas might not be the best when applied elsewhere in the tree. As such, starting a GLEP is probably the best approach, elsewise, this idea will just die on the mailing lists yet again. I'm just not sure when I'll have some free time to educate myself on GLEPs and throw a draft together. I've lately been trying to chase a really obscure kernel bug down on one of my SGI systems in addition to other life responsibilities, so a GLEP is somewhat low priority right now. -- Joshua Kinard Gentoo/MIPS kumba@gentoo.org 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic