https://bugzilla.redhat.com/show_bug.cgi?id=1834731 --- Comment #102 from Simone Caronni <negativo17@xxxxxxxxx> --- (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 _______________________________________________ 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
