Anthony G. Basile:
> Hi everyone,
>
> I proxy a set of bitcoin ebuilds for Luke-jr. Currently several ebuilds
> make use of the same codebase, so its probably a good idea to migrate
> that code to an eclass. Can we have the following eclass reviewed
> before committing it to the tree:
>
> https://gitorious.org/bitcoin/gentoo/source/674d32a2d029aed3bc967a1949f75586828ebe14:eclass/bitcoincore.eclass
>
>
Afais the eclass is missing the safeguard, as in
if [[ -z ${_BITCON_ECLASS} ]]; then
...eclass-code...
fi
Why is EAPI=5 not supported?
Why does it not use git-r3?
Are you sure all ebuilds that will use this eclass have the same
HOMEPAGE? We had this with qt eclass once and it wasn't really correct,
but rather a convenience shortcut.
A lot of code is posix-style, not bash-style. But I'm not sure if we care.
I don't understand why bitcoincore_pkg_pretend(), bitcoincore_src_test()
are defined twice. I think you mistyped the names here slightly.
line 169, 170 and 222 seem to lack a "|| die"
autoreconf is not reliable and we know that it sometimes unpredictably
fails. Running it unconditionally is a bit strong, no?
bitcoincore_conf() looks like it could make use of 'usex' and
'use_enable' instead of those difficult to read if-else conditions.
I'm still not sure why we need to put nongeneric eclasses in eclass/ and
cannot put them inside the ebuild dir.
