https://bugzilla.redhat.com/show_bug.cgi?id=1834731
--- Comment #102 from Simone Caronni <negativo17(a)gmail.com> ---
(In reply to Warren Togami from comment #74)
Points of Agreement:
* Rename package to "bitcoincore"
Actually "bitcoin-core", but same result.
* EL7's boost is too old while EL8+ and Fedora are easy to
support. Let's
drop EL7 and documentation should say to use bitcoincore.org's builds on
EL7. The plan to maintain a work-alike package suitable for upstream builds
so this should be convenient enough for end-users.
The only problem is how Boost is searched, it expects ../include/boost from
where the libraries are found. Theoretically it should work with a bit of
fiddling but there are too many compromises anyway, so it has been dropped.
* How about rename the 'core' subpackage to 'qt'
since that is what it
contains?
I've renamed it to 'desktop', so now all RPMS are subpackages of the main
'bitcoin-core' name for clarity (bitcoin-core-desktop).
* bitcoin-wallet is actually a utility? It isn't a required part
for the
server to function.
It's a tool that might come handy and allows manipulating and creating wallets
from the command line, so I'm not deleting it.
"By default bitcoin-cli looks for configuration at
/etc/bitcoin/bitcoin.conf. This must be readable only by users authorized to
communicate with bitcoind."
These binaries should behave the same as upstream's builds. The
$HOME/.bitcoin/bitcoin.conf default path should remain supported so it
behaves identically to upstream builds. I haven't tested if this isn't the
case now.
As already discussed this is the default. By default it looks in
/etc/bitcoin/bitcoin.conf and if not found it looks in
$HOME/.bitcoin/bitcoin.conf, so no changes here.
* server vs core subpackage kind of bother me because while you
don't use
bitcoind and bitcoin-qt simultaneously they are functionally identical. I
don't know what to suggest about this.
Already answered above, server is headless and might have client on another
system, the main QT application is for desktops, so makes sense to have them as
three separate packages depending on usage.
* The bitcoin.service file bothers me in that a single system service
is one
of many ways in which bitcoind is used. I'd prefer if it was a .service type
that allowed for multiple admin "@" definable instances. There could also be
a different .service file like "bitcoincore-homedir-service" that uses
$HOME/.bitcoin as the datadir in the way many have already deployed the
upstream binary? It is also my strong preference for the different types of
.service files to be in their own subpackage. That would also help the above
concern regarding a single hard-coded /etc/bitcoin/bitcoin.conf not being
how many use this software.
That's actually not true, in the source code you also have a sample systemd
unit with explicit hardcoded paths.
I will investigate if it's feasible to include _also_ systemd user instantiable
units in the server package without requiring to destroy completely the SELinux
policies.
(In reply to Warren Togami from comment #76)
The test suite is *excessively slow*. IMO we should not run these
extensive
tests during these builds. Upstream official builds do not. We developers
should instead run these tests on the target platforms independently.
The tests make sure that the binaries built are working, if they fail some test
then the package build fails. They are not part of what the users see.
I would say they are CRITICAL to make sure you have fully functioning binaries.
Hard Line:
* The official supported file format of wallet.dat is db4. "./configure
--with-incompatible-bdb" is named as such because it is not intended to be
used by distributors. It exists as an unsupported option so the software is
possible to use where db4 does not conveniently exist. I strongly advise
against shipping an incompatible data format in a package that may be widely
used as it will be an inevitable point of support confusion. The software
should work identically when switching between Fedora or upstream's build.
The only maintainable choice here is to ship exactly the db4 that upstream
maintains and tests against within this package. Future Bitcoin Core will
migrate to a different database but it will forever need to link to db4 to
allow for automatic wallet migration.
BDB 4.8 is not in fact "conveniently existing" in Fedora, it has been retired
for quite some time, it's dated 2010-04-12 (!) and requires some effort to
actually bundle:
https://github.com/bitcoin/bitcoin/blob/master/contrib/install_db4.sh
I will see what I can do, but there's not even guarantee it builds with recent
compilers in Fedora.
* Conflicts: bitcoin
* Ask FESCO to disallow any package named "bitcoin".
Not asked yet.
(In reply to Warren Togami from comment #81)
(In reply to Warren Togami from comment #77)
> Regarding bitcoin.service:
>
> Restart=on-failure
> TimeoutStopSec=120
> TimeoutStartSec=60
> StartLimitInterval=240
> StartLimitBurst=5
>
> There exists a corner case where "stop" can take significantly more time
> than any amount hardcoded here. Force kill in that situation causes data
> corruption and an even more time consuming recovery the next time indexing
> begins again. I asked my engineers here if they came up with a better way to
> detect a safe stop.
PrivateTmp=true
TimeoutStopSec=1200s
TimeoutStartSec=5s
# Fail when 10 tries within 1 minute fail (never)
StartLimitInterval=60s
StartLimitBurst=10
# Limit attempts to 1 per 10 seconds
Restart=always
RestartSec=10
This is what we've been using in prod here. We didn't find a more
intelligent solution. Under normal operation it stops relatively fast but in
rare situations it needs the extra time to cleanly shut down.
Will check along the user systemd unit.
--
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
https://bugzilla.redhat.com/show_bug.cgi?id=1834731