Re: [gentoo-dev] Require opt-in for bitcoin upgrade?
On 2021-07-10 17:18, William Hubbs wrote: To update everyone involved in this, please read my last comment on the pr. Basically, this can be treated like a test version by adding it to package.mask with an appropriate message then maybe publishing a newsitem if the maintainer wants it to be known by other users. William IMHO, a news item is a bit much... I feel that the package.mask message is sufficient. Huge thank you to all participants for discussing the topic and coming up with the package.mask idea! Here's a PR which is hopefully agreeable: https://github.com/gentoo/gentoo/pull/21587 ~Craig
Re: [gentoo-dev] Require opt-in for bitcoin upgrade?
To update everyone involved in this, please read my last comment on the pr. Basically, this can be treated like a test version by adding it to package.mask with an appropriate message then maybe publishing a newsitem if the maintainer wants it to be known by other users. William signature.asc Description: PGP signature
Re: [gentoo-dev] Require opt-in for bitcoin upgrade?
Hey All, I'm responding again because I saw that I left Luke off of my original message and I cleaned up my steps a bit. We talked about this on the irc channel, and several of us feel that you don't need anything special in the ebuild at all, you can do this via package.mask and a newsitem. I suggest the following assuming that the older version will stop working when the network is fully upgraded. - Publish a newsitem explaining this issue. - After the newsitem is published, Commit the newer version under package.mask with the mask message being an explanation of the issue. - at this point, if people want to opt in, they can unmask the newer version and add it to package.accept_keywords. - Once the network is upgraded, unmask the newer version (and you might have to fast stable if the older version doesn't work). - If I understand correctly, at this point, opting in isn't optional since the network is upgraded, so if people don't want to use the new algo they can't use bitcoin. That will give everyone time to see the newsitem before the newer version hits. It seems like this is the best you can do since upstream is doing a hard switchover to the new algo. William signature.asc Description: PGP signature
Re: [gentoo-dev] Require opt-in for bitcoin upgrade?
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 signature.asc Description: PGP signature
[gentoo-dev] Require opt-in for bitcoin upgrade?
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] 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. 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] Thank you for your consideration and assistance with this issue, ~Craig [1] https://github.com/gentoo/gentoo/pull/21490 [2] https://taproot.watch/ [3] https://github.com/gentoo/gentoo/pull/21490#discussion_r663201705 [4] https://github.com/gentoo/gentoo/pull/21490#issuecomment-877542346 [5] https://github.com/gentoo/gentoo/commit/e62b85aae5a2dd70ff120ebc284bf6d461e34b88#diff-e5afbd0e114be010e271302d0807aba076083d0e623ddd611f7e80b4b02a1c82R91 [6] https://github.com/gentoo/gentoo/pull/21490#issuecomment-877531697 signature.asc Description: OpenPGP digital signature