| 1 |
Anthony G. Basile: |
| 2 |
> Hi everyone, |
| 3 |
> |
| 4 |
> I proxy a set of bitcoin ebuilds for Luke-jr. Currently several ebuilds |
| 5 |
> make use of the same codebase, so its probably a good idea to migrate |
| 6 |
> that code to an eclass. Can we have the following eclass reviewed |
| 7 |
> before committing it to the tree: |
| 8 |
> |
| 9 |
> https://gitorious.org/bitcoin/gentoo/source/674d32a2d029aed3bc967a1949f75586828ebe14:eclass/bitcoincore.eclass |
| 10 |
> |
| 11 |
> |
| 12 |
|
| 13 |
|
| 14 |
Afais the eclass is missing the safeguard, as in |
| 15 |
|
| 16 |
if [[ -z ${_BITCON_ECLASS} ]]; then |
| 17 |
|
| 18 |
...eclass-code... |
| 19 |
|
| 20 |
fi |
| 21 |
|
| 22 |
Why is EAPI=5 not supported? |
| 23 |
|
| 24 |
Why does it not use git-r3? |
| 25 |
|
| 26 |
Are you sure all ebuilds that will use this eclass have the same |
| 27 |
HOMEPAGE? We had this with qt eclass once and it wasn't really correct, |
| 28 |
but rather a convenience shortcut. |
| 29 |
|
| 30 |
A lot of code is posix-style, not bash-style. But I'm not sure if we care. |
| 31 |
|
| 32 |
I don't understand why bitcoincore_pkg_pretend(), bitcoincore_src_test() |
| 33 |
are defined twice. I think you mistyped the names here slightly. |
| 34 |
|
| 35 |
line 169, 170 and 222 seem to lack a "|| die" |
| 36 |
|
| 37 |
autoreconf is not reliable and we know that it sometimes unpredictably |
| 38 |
fails. Running it unconditionally is a bit strong, no? |
| 39 |
|
| 40 |
bitcoincore_conf() looks like it could make use of 'usex' and |
| 41 |
'use_enable' instead of those difficult to read if-else conditions. |
| 42 |
|
| 43 |
|
| 44 |
|
| 45 |
I'm still not sure why we need to put nongeneric eclasses in eclass/ and |
| 46 |
cannot put them inside the ebuild dir. |
Archives