Luke Dashjr:
> 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?
>
Why is that important? git-r3 has shallow clones.
>> 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.
>
> Technically, Bitcoin Core doesn't really have any website.
> For technical reasons, bitcoin.org is where we upload the release binaries.
> I suppose we could point it at the GitHub URI, but that's not very user-
> friendly...
>
A lot of packages point to GitHub URI. I think that's reasonable.
At least sth like
HOMEPAGE+=" github-uri"
>> 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?
>
I was implicitly asking if there are never any configure scripts already
generated and if all patches touch the build system.
>> 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.
>
if_iusex() { use_if_iuse "$1" && echo "${2-yes}$4" || echo "${3-no}$5" ; }
if_iuse_enable() {
local UWORD=${2:-$1}
local UE_SUFFIX=${3+=$3}
if use_if_iuse $1; then
echo "--enable-${UWORD}${UE_SUFFIX}"
else
echo "--disable-${UWORD}"
fi
}
Another thing I just found:
# @FUNCTION: in_iuse
[...]
# Note that this function should not be used in the global scope.
Seems you use it in global scope.
