| 1 |
On 03/21/2017 09:28 AM, Joshua Kinard wrote: |
| 2 |
> In general, the concept of code-sharing common blocks of logic between multiple |
| 3 |
> ebuilds in a specific package directory that is not a top-level eclass is not |
| 4 |
> entirely without merit. But the only way this idea can be realized in a |
| 5 |
> suitable manner and be used by far more consumers than today's eblits are, is |
| 6 |
> to either find and finish the old elibs GLEP or start one over from scratch, |
| 7 |
> submit whatever needs submitting via patches to at least PMS and Portage, work |
| 8 |
> through whatever processes are required for approval, and then deploy it in the |
| 9 |
> next EAPI. |
| 10 |
> |
| 11 |
> If anyone is game for working something up or discussing further, let me know. |
| 12 |
|
| 13 |
I personally fail to see good reasons to have a separate approach for |
| 14 |
this instead of putting it in the eclass framework. However this might |
| 15 |
simply mean I'm missing something in the discussion. |
| 16 |
|
| 17 |
Before restarting such a GLEP process; maybe a simple pros and cons list |
| 18 |
of comparison of the future eblit use and existing eclass structure |
| 19 |
could be helpful? (along with more description of the differences) |
| 20 |
|
| 21 |
-- |
| 22 |
Kristian Fiskerstrand |
| 23 |
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net |
| 24 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |
Archives