Re: [gentoo-dev] Require opt-in for bitcoin upgrade?

[William Hubbs]

On Sat, Jul 10, 2021 at 11:42:28AM -0400, Craig Andrews wrote:
> Gentoo currently has a number of packages required to run a bitcoin node
> in its tree, including:
> * net-libs/libbitcoinconsensus
> * net-p2p/bitcoin-qt
> * net-p2p/bitcoind
>
> In version 0.21.1, bitcoin included a consensus algorithm changed call
> taproot. There is no configuration opt-in with this change; bitcoin <
> 0.21.1 does not include taproot, bitcoin >= 0.21.1 does include taproot.
>
> A PR [1] was created the bitcoin packaging proxy maintainer (Like
> Dash-Jr, CC'ed) for the bitcoin 0.21.1 version bump. In that PR, Luke
> insists that users must explicitly opt-in to the bitcoin 0.21.1 upgrade
> because of the taproot consensus algorithm change. I encourage
> interested parties to read the conversation in that PR to get the full
> context.
>
> * This is a minor version bump (assuming semver, this is the "patch"
> level version change in bitcoin), indicating that upstream does not
> consider this to be a major/breaking change.
> * Upstream does not have a mechanism for notifying users or requiring
> them to opt-in to this change
> * Upstream does not have a mechanism to opt out of this change. The
> users only option is to develop their own fork of the bitcoin software
> or never upgrade the package if they want to avoid taproot.
> * Taproot was locked by miners, so the network will be upgrading [2]

I suggest the following:

1) a newsitem explaining this issue.
2) at the same time, package.mask the newer version temporarily and keep
the older version in the tree.
3) Once the network is upgraded, unmask the newer version and drop the
older version. If people want the older version at that point and write
a fork, you'll have to rename itt.

>
> Therefore, I have a few questions for the fellow Gentoo developers:
> 1) Should we require users to explicitly opt-in to this upgrade beyond
> the usual?
> 2) If so, how do we do that? I have been unable to find any
> documentation or examples of existing packages that require explicit
> upgrade opt-in. A REQUIRED_USE or a LICENSE [3] were suggested as well
> as PROPERTIES="interactive" [4], but such approaches seem like
> unintended/unconventional abuses of those settings as well as annoying
> to the user.

If you do, I think you can do it the way I suggested without adding
extra things to the ebuild.

>
> My suggested approach was to notifying the user of the change in the
> pkg_pretend phase [5] so they're aware before they actually upgrade;
> however, the proxy maintainer disagreed and force a revert. [6]

As far as I know proxy maintainers can't force anything; they defer to
developers because we are the ones who are more familiar with the way
the tree works.

That being said, I still think the cleaner solution is to use
a temporary package.mask along with a newsitem.

Thanks,

William