| 1 |
On 03/21/2017 04:43, Kristian Fiskerstrand wrote: |
| 2 |
> On 03/21/2017 09:28 AM, Joshua Kinard wrote: |
| 3 |
>> In general, the concept of code-sharing common blocks of logic between multiple |
| 4 |
>> ebuilds in a specific package directory that is not a top-level eclass is not |
| 5 |
>> entirely without merit. But the only way this idea can be realized in a |
| 6 |
>> suitable manner and be used by far more consumers than today's eblits are, is |
| 7 |
>> to either find and finish the old elibs GLEP or start one over from scratch, |
| 8 |
>> submit whatever needs submitting via patches to at least PMS and Portage, work |
| 9 |
>> through whatever processes are required for approval, and then deploy it in the |
| 10 |
>> next EAPI. |
| 11 |
>> |
| 12 |
>> If anyone is game for working something up or discussing further, let me know. |
| 13 |
> |
| 14 |
> I personally fail to see good reasons to have a separate approach for |
| 15 |
> this instead of putting it in the eclass framework. However this might |
| 16 |
> simply mean I'm missing something in the discussion. |
| 17 |
> |
| 18 |
> Before restarting such a GLEP process; maybe a simple pros and cons list |
| 19 |
> of comparison of the future eblit use and existing eclass structure |
| 20 |
> could be helpful? (along with more description of the differences) |
| 21 |
|
| 22 |
Well, maybe it's a sign of my age and tenure, but I always thought one should |
| 23 |
be conservative in the definition of new eclasses. I may be wrong, but back in |
| 24 |
the old days, to define a new toplevel eclass, I believe one had to demonstrate |
| 25 |
that a number of different packages all had common ebuild logic that could all |
| 26 |
merged into a single eclass. Kinda like what we do now with new global USE |
| 27 |
flags. So throwing package-specific eclasses into the toplevel eclass |
| 28 |
directory seems to run against this. Additionally, repoman does not validate |
| 29 |
the logic in eclasses currently (a long-time issue), which can lead to code rot |
| 30 |
of such package-specific common code. |
| 31 |
|
| 32 |
That said, I'm not wedded to the current implementation of eblits as they |
| 33 |
exist, and IMHO, I do agree in principle with QA that any such feature like |
| 34 |
that needs to be defined in PMS and employed by the package manager in some |
| 35 |
capacity. It is certainly doable right now with an eclass (I even have an |
| 36 |
example eblit.eclass that demos this), but it would be better to leverage |
| 37 |
existing loading and sourcing logic within the package managers for such a |
| 38 |
capability, which means changing them and updating PMS, which effectively means |
| 39 |
a new EAPI. |
| 40 |
|
| 41 |
How we go about implementing this idea, or whether we even bother to do so, is |
| 42 |
what needs to be discussed. I certainly have some ideas, but I've largely |
| 43 |
isolated myself to the MIPS world the last few years and my ideas might not be |
| 44 |
the best when applied elsewhere in the tree. As such, starting a GLEP is |
| 45 |
probably the best approach, elsewise, this idea will just die on the mailing |
| 46 |
lists yet again. I'm just not sure when I'll have some free time to educate |
| 47 |
myself on GLEPs and throw a draft together. I've lately been trying to chase a |
| 48 |
really obscure kernel bug down on one of my SGI systems in addition to other |
| 49 |
life responsibilities, so a GLEP is somewhat low priority right now. |
| 50 |
|
| 51 |
-- |
| 52 |
Joshua Kinard |
| 53 |
Gentoo/MIPS |
| 54 |
kumba@g.o |
| 55 |
6144R/F5C6C943 2015-04-27 |
| 56 |
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 |
| 57 |
|
| 58 |
"The past tempts us, the present confuses us, the future frightens us. And our |
| 59 |
lives slip away, moment by moment, lost in that vast, terrible in-between." |
| 60 |
|
| 61 |
--Emperor Turhan, Centauri Republic |
Archives