| 1 |
rindeal posted on Fri, 27 May 2016 00:28:35 +0200 as excerpted: |
| 2 |
|
| 3 |
> I've noticed that ebuilds for at least dev-lang/perl and sys-libs/glibc |
| 4 |
> are using some concept of "eblits", which seems like parts of ebuilds |
| 5 |
> scattered across $FILESDIR with ebuilds containing some logic (involving |
| 6 |
> eval) which includes and runs them. |
| 7 |
> |
| 8 |
> I haven't found any documentation related to them so I'm asking here: |
| 9 |
> |
| 10 |
> 1) what are they? |
| 11 |
> 2) why are they used? |
| 12 |
|
| 13 |
Consider this answer a "gap" answer, until you get a better answer from |
| 14 |
Frysinger (who I believe is the one who invented the concept, or failing |
| 15 |
that, at least one of the primary users and expanders of the concept for |
| 16 |
the glibc ebuilds) or one of the perl devs that are directly involved, or |
| 17 |
QA... |
| 18 |
|
| 19 |
Based on (obviously my understanding of) the explanations I've seen |
| 20 |
previously, you can think of them sort of like eclasses, reusable |
| 21 |
libraries used by multiple ebuilds, except that they're normally specific |
| 22 |
to the multiple ebuilds for a single package, instead of being code |
| 23 |
shared between many different packages. |
| 24 |
|
| 25 |
Because they're normally only used by the different ebuilds for a single |
| 26 |
package, generally maintained by the same person, they don't have the |
| 27 |
same formality applied to them that eclasses do. Eclass changes are |
| 28 |
normally posted here on the dev list for review before being committed, |
| 29 |
for instance, while eblits... not. |
| 30 |
|
| 31 |
However, as a result of this informality and the subsequent gray area |
| 32 |
eblits inhabit, they tend to be discouraged for most packages and |
| 33 |
definitely for newer devs. In general, for in-tree use and for repos |
| 34 |
following the same rules, consider eblits an "if you have to ask, it's |
| 35 |
not an option available to you" deal. Alternatively put, if you believe |
| 36 |
they'd be useful for code destined for in-tree use, definitely consult |
| 37 |
with other devs and with QA before attempting to introduce your eblits, |
| 38 |
and be prepared for a "no" answer. |
| 39 |
|
| 40 |
-- |
| 41 |
Duncan - List replies preferred. No HTML msgs. |
| 42 |
"Every nonfree program has a lord, a master -- |
| 43 |
and if you use the program, he is your master." Richard Stallman |
Archives