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 |