https://bugzilla.redhat.com/show_bug.cgi?id=1834731 --- Comment #71 from Simone Caronni <negativo17@xxxxxxxxx> --- (In reply to Warren Togami from comment #70) > * Fedora's package should be named "bitcoincore". It should conflict with > "bitcoin". This would allow a popular feature-fork "bitcoinknots" would have > the same binary and configuration files and would thus conflict with these > other names. Fine, I will make the necessary adjustments. > * Ask FESCO to disallow any package named "bitcoin". There are multiple > reasons for this including unexpected upgrade conflicts with ways it was > previously packaged. It is also convenient for distributors to entirely > sidestep political fights over what has the right to be called "bitcoin". Fine for me as well. > * Less important: Another upstream concern is the risk of old bitcoin > binaries in the wild when Fedora goes EOL. The simplest safeguard is to ship > a final RPM update before a Fedora release's EOL that simply removes the > binary. We would ask FESCO if they're OK with this. I think this solves nothing (someone could still avoid installing the updates, fetching an old package or we could just miss a release retirement because of a person being on holiday, etc. Same applies for manually installed binaries, there is no way to enforce that. If you want it I'm fine with that, but again I think it's completely useless. > FYI: Years ago the linked library dependencies were a terrible risk of > causing consensus failure. It was beyond hypothetical risk, it actually > happened to unmaintained clones who failed to heed CVE's. That previous risk > was mostly mitigated by the removal of openssl. Upstream aims to eventually > eliminate the boost dependency which would further reduce risk. In any case > the risk is low enough now that it might be OK to ship in downstream > distros. I'm fine with this as well and will try to keep it in sync as possible with these dependencies slated for removal. > Don't mistake this as endorsement. I intend for upstream to > distribute a reproducibly built RPM that would Epoch override the Fedora > package for those who prefer static libraries exactly as tested by upstream. > Upstream opposes automatic upgrades of Bitcoin Core so this would be a way > for Fedora users to opt-in to upstream's recommended deployment method. This > isn't Fedora's concern but just explaining the line of reasoning here. I'm willing to keep it updated / in sync with upstream for the time being, so we can ensure a smooth upgrade path for whoever wants to use official binaries. Count me in if you think I should contribute to the upstream's SPEC file and SELinux policies. I'm fine also in integrating Guix as conditionals in the SPEC file to allow building from the same SPEC file (e.g. hosted upstream, non-guix build in fedora, higher epoch and guix build upstream). Are you ok with these points? -- 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
