On Fri, Feb 06, 2015 at 02:46:37AM +0000, Luke Dashjr wrote:
> On Friday, February 06, 2015 2:10:31 AM hasufell wrote:
> > Why does it not use git-r3?
>
> I just looked into this, and I don't see a way to get git-r3 to use the same
> repositories already cloned for previous versions. What is the standard
> practice for ebuilds already using git-2?
It might handle that automatically, there are some references in the
eclass about it but i am far from an expert on that eclass.
Also, there is the EGIT_COMMIT variable, so you can remove the whole
BITCOINCORE_COMMITHASH bit.
also:
if [ -z "$BITCOINCORE_COMMITHASH" ]; then
inherit git-2
is weird, it's normally if [[ ${PV} = *9999* ]]
> > I don't understand why bitcoincore_pkg_pretend(), bitcoincore_src_test()
> > are defined twice. I think you mistyped the names here slightly.
>
> This was a remnant from an older version of the eclass, removed.
Is bitcoincore_src_test needed at all? The default src_test function
will do exactly the same thing (and better) so you can remove this and
just let the default be used.
Also, why does bitcoincore_src_install call bitcoincore_install? why
have two functions that are the same?
I would probably do:
bitcoincore_src_install() {
default
[ "${PN}" = "libbitcoinconsensus" ] || rm "${D}/usr/bin/test_bitcoin"
}
> > autoreconf is not reliable and we know that it sometimes unpredictably
> > fails. Running it unconditionally is a bit strong, no?
>
> What should be used instead, to generate configure etc?
>
> > bitcoincore_conf() looks like it could make use of 'usex' and
> > 'use_enable' instead of those difficult to read if-else conditions.
>
> These will give QA issues for ebuilds that don't have the applicable USE flag
> available in IUSE.
how about: in_iuse flag && my_econf = "${my_econf} $(use_enable flag)"
I dont really understand the pkg_pretend stuff, shouldnt all that stuff
be in the useflag descriptions?
