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 ku...@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
