Συντάκτης: Hendrik Boom Ημερομηνία: Προς: dng Αντικείμενο: Re: [DNG] leveldb support proposal
On Wed, Mar 02, 2016 at 12:45:22PM +1300, Daniel Reurich wrote: > On 26/02/16 05:01, Ivan J. wrote:
> > Hello DnG.
> >
> > Is there interest in Devuan supporting multiple versions of leveldb?
>
> It is possible, but is it necessary??
> It would should be relatively easy to forward port the libdb4.8 package
> from squeeze.
>
> > Why I am wondering is because of Bitcoin and its code. Currently Bitcoin
> > statically links db-4.8 and it is used for having wallet support in
> > Bitcoin Core.
> Are you talking about bitcoin in general or bitcoin in debian|devuan?
>
> Are we talking about leveldb or berkely db (package libdb-<version>??
> You ask about leveldb and then refer to berkely db versions...
>
> > Where the problem arises is when you try to build Bitcoin Core yourself.
>
> > You need to compile with db-4.8 libraries, and we all know distros have
> > dropped it in favor of 5.x... Using system leveldb on distros requires
> > higher QA for leveldb than typical.
>
> Can it not be made to build against db-5.3? If not, why not?
>
> > What I am proposing is Devuan to support multiple versions of leveldb
> > and tie Bitcoin packages to the right one. Another option is to never
> > push updates to leveldb until they are known consensus-safe. It would be
> > awesome if Devuan could be the second distro to meet the higher
> > standards required for the Bitcoin code; for example, a bugfix to
> > leveldb could cause serious security problems with Bitcoin. (This is why
> > it's statically linked for almost every distro).
>
> Sure, but the question this raises in my mind is; Is their a proven
> issue with db-5.3 that has been introduced that breaks bitcoin-core or
> adds security threats?
>
> The risk is that issues that have been fixed in later libdb versions
> remain broken in the version that bitcoin statically links in. So there
> is a trade off either way, and what is the better approach... fix
> bitcoin or forever hold onto an obsolete library for one package where
> the maintainers refuse to switch to a newer version.
It's probably the job of the bitcoin developers to watch deveopments
in that other library and decide when it is safe or necessary to change
versions.