On Friday, February 06, 2015 4:24:58 AM Jason Zaman wrote:
> 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.
It's only using git for the 9999 version, and BITCOINCORE_COMMITHASH is for
the non-9999 version(s).
> > > 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"
> }
Ok, changed.
> > > 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)"
If it's not in IUSE, I still want to pass --disable-flag
> I dont really understand the pkg_pretend stuff, shouldnt all that stuff
> be in the useflag descriptions?
It's there too, but people weren't reading it, which gave some justification
to some "rioting" from trolls a while back. From an upstream perspective, it's
also important that users are aware of and make actual policy decisions rather
than just using whatever happens to be default - it puts undue pressure on the
development team to change the defaults to satisfy different opposing
groups/viewpoints when we'd rather just focus on writing the code.
Updated eclass:
https://gitorious.org/bitcoin/gentoo/source/b4f1b6a0a9436639ef9ec658a1e90975318d746f:eclass/bitcoincore.eclass
Luke
