unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: Carl Dong <contact@carldong.me>, zimoun <zimon.toutoune@gmail.com>
Cc: 34170@debbugs.gnu.org
Subject: bug#34170: bitcoin-core bundles leveldb
Date: Wed, 05 Jan 2022 19:13:57 +0000	[thread overview]
Message-ID: <563546ec57ff4726bf4138c16be6304c869119ce.camel@telenet.be> (raw)
In-Reply-To: <26B84833-6F9F-4C5D-8448-715C67C16768@carldong.me>

[-- Attachment #1: Type: text/plain, Size: 2999 bytes --]

Hi,

Carl Dong schreef op wo 05-01-2022 om 12:40 [-0500]:
> Simon, Maxime, Danny,
> 
> Thanks for CCing me on this message! The rationale for bundling
> leveldb in Bitcoin Core goes a bit beyond convenience, it is several
> things:
> 
> 1. The original reason for sub-treeing is that Bitcoin Core used to
> maintain its own version of leveldb with its own fixes
> here: https://github.com/bitcoin-core/leveldb-subtree, since then
> most of these fixes have been upstreamed as
> of: https://github.com/bitcoin/bitcoin/pull/17398

Seems reasonable to me, but the bitcoin project is upstreaming the
changes it made and most are already upstream, so I would prefer
to use upstream's leveldb.

> 2. We also used to support using an external leveldb, however, it
> seems that it was fragile to rely on external projects to maintain
> ABI compatibility, see the quoted IRC bug report
> here: https://github.com/bitcoin/bitcoin/pull/23282. Reasonable minds
> may disagree on this point, especially coming from Guix where
> patching is convenient.

The quoted ABI incompatibility

    <Talkless> bitcoind fails to start with undefined symbol:
_ZTIN7leveldb6LoggerE in Debian Sid after leveldb upgraded from 1.22 to
1.23: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996486

doesn't apply in Guix, because guix uses RUNPATH and multiple library
versions can exist in the same store (in different directories in the
store).

> In addition to the above, Bitcoin Core experienced a hard fork in
> 2013 due to database incompatibilities, which has predisposed
> maintainers towards a more stringent approach with pinning
> dependencies and their configure/build-time flags.
> See: https://blog.bitmex.com/bitcoins-consensus-forks/#was-the-2013-
> incident-a-hardfork

I doubt that Guix has sufficient Bitcoin Core users to cause
a hard fork, but yes, this is an understandable reason to bundle
things.  But any such problem seems easy to resolve (at the guix side):
we could simply temporarily switch to an older version of leveldb.

If desired, it would also be possible to do something in-between
unbundling and using bitcoin's leveldb: define a 'leveldb/bitcoin'
variant of the 'leveldb' package (using package/inherit or (package
(inherit ...) ...)), add it as input to the 'bitcoin' package and tell
and/or patch bitcoin's buid scripts to use that leveldb.

As source code, use an appropriate commit from
<https://github.com/bitcoin-core/leveldb-subtree> (and add a comment
to the definition of bitcoin-core to keep leveldb/bitcoin in-sync).

A benefit of this approach (if done properly, with (origin (inherit
...) ...) such that patches of 'leveldb' are inherited) above the
status quo, is that is that if for some reason 'leveldb' is patched in
Guix, then 'leveldb/bitcoin' receives the patch as well. Another
benefit is that the dependency 'googletest' and 'benchmark' of leveldb
would remain unbundled.

Greetings,
Maxime.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

  reply	other threads:[~2022-01-05 19:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-22 12:31 bug#34170: bitcoin-core bundles leveldb Danny Milosavljevic
2021-12-03 10:29 ` zimoun
2022-01-04 23:29   ` zimoun
2022-01-05  9:39   ` Maxime Devos
2022-01-05  9:45     ` zimoun
2022-01-05 17:40       ` Carl Dong
2022-01-05 19:13         ` Maxime Devos [this message]
2022-01-07  0:17           ` Carl Dong
2022-07-13 15:10             ` Maxim Cournoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=563546ec57ff4726bf4138c16be6304c869119ce.camel@telenet.be \
    --to=maximedevos@telenet.be \
    --cc=34170@debbugs.gnu.org \
    --cc=contact@carldong.me \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).