https://bugzilla.redhat.com/show_bug.cgi?id=1834731



--- Comment #52 from Warren Togami <wtog...@gmail.com> ---
> For the 0.21 release something has changed in the boost code, so Boost as 
> provided by the base distribution in CentOS/RHEL 7 is no longer enough.

I have a plan to fix this and more for RHEL7+ and Fedora in a uniform way. It
might take a few weeks for this to be ready. I can explain it sooner if you
would like to talk.

Sorry for injecting myself into this after you've put half a year of work into
this. You disregarded critical warnings in Bug #1020292 as to why packaging
this is hazardous. There are risks you are not familiar with as to why
historically none of the leading distros (Fedora, Debian, Ubuntu) have packaged
Bitcoin Core. Tldr: Builds dynamic linked to system libraries have previously
been vulnerable to catastrophic network divergence. Distribution packages
wouldn't be dangerous if only a few people used it. But should they become the
most common way of using Bitcoin Core then it would be a systemic risk. This
was not only a hypothetical problem. BIP66 is one such historical example that
could have been exacerbated by distro packages becoming the most common way to
run Bitcoin Core full nodes.

The safer way for downstream distributions to handle this not become possible
until recent upstream work (Guix-related). There's three step needed to make
this usable for Fedora/RHEL.

1) Guix-based deterministic builds of Bitcoin Core to become the official
release process (replacing their previous Ubuntu-based Gitian). This work is
now 99% complete.

2) Add rpmbuild to upstream's Guix build process. It would generate
deterministic binary RPMS alongside their binary tarballs.

https://salsa.debian.org/debian/guix/-/tree/debian/devel/debian
https://github.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROOT.org

3) Package Guix for Fedora much in the same way as Debian did it. This would
allow us to have a known deterministic build system that is capable of building
identical binaries.

I did not appreciate how you closed Bug #1020292 and disregarded the warnings
written there. Out of respect I am not unilaterally closing this bug.

Step #2 above is an opportunity to collaborate. I assigned one of my engineers
to work on this. We should collaborate on what exactly we want to be in a
bitcoincore RPM package. For example instead of your -server package we may
want to consider systemd service @ units as an official way to configure and
launch multiple nodes.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
_______________________________________________
package-review mailing list -- package-review@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/package-review@lists.fedoraproject.org

Reply via email to