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) -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
signature.asc
Description: OpenPGP digital signature
