| 1 |
On 27 May 2016 at 10:28, rindeal <dev.rindeal@×××××.com> wrote: |
| 2 |
> |
| 3 |
> 1) what are they? |
| 4 |
> 2) why are they used? |
| 5 |
|
| 6 |
|
| 7 |
My best explanation is its a way to re-use very large amounts of code |
| 8 |
between 2 ebuilds, without resorting to: |
| 9 |
|
| 10 |
a) Copying the whole ebuild and hoping you find the relevant part in diffs |
| 11 |
b) Not needing reams of version-specific conditional code to make |
| 12 |
copying ebuilds between versions easier. |
| 13 |
c) Not needing confusing eclasses that exist to serve a single |
| 14 |
package, loaded with lots of weird conditional logic. |
| 15 |
|
| 16 |
My understanding is you could effectively roll the eblits back into |
| 17 |
the ebuild statically, just doing so would make keeping the changes |
| 18 |
consistent harder. |
| 19 |
|
| 20 |
Its clearly designed for a system where you have ~10 different |
| 21 |
versions of Perl available or ~10 different versions of glibc |
| 22 |
available, but you don't want to pay the price of duplicating that |
| 23 |
logic wholesale for every minor concurrent revision, and only want to |
| 24 |
update essential differences when you need to, not because you have |
| 25 |
to. |
| 26 |
|
| 27 |
That said, its a very confusing system to get your head around, |
| 28 |
because its *basically* yet another "mixin" system like "inherit", but |
| 29 |
done in bash, which itself is a rather strange language to be doing |
| 30 |
something as complicated as mixins. |
| 31 |
|
| 32 |
-- |
| 33 |
Kent |
| 34 |
|
| 35 |
KENTNL - https://metacpan.org/author/KENTNL |
Archives