https://bugzilla.redhat.com/show_bug.cgi?id=1834731
--- Comment #71 from Simone Caronni <negativo17(a)gmail.com> ---
(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