Noel Torres <envite@???> writes:
> Let's forget what is NOT important
>
> "Ivan J." <parazyd@???> escribió:
> [...]
>> 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
> [...]
>
> This is not only an issue with so-called leveldb. It happens a lot
> that two packages you need request different versions of the same
> library, not always co-installable. Mostly if you go beyond "stable".
> Or even if you got stuck on oldstable and try to install some simple
> new package.
>
> And this is a good amount of the "dependency hell" when it comes to
> Desktop users.
>
> So, I think that having some way of installing multiple versions of
> the same library would be a useful feature.

But this already exists. Eg, the machine I usually use for development
(Debian 6 based) has the following version of libdb installed:

ii  libdb4.2         4.2.52+dfsg-5     Berkeley v4.2 Database Libraries [runtime]
ii  libdb4.5         4.5.20-13         Berkeley v4.5 Database Libraries [runtime]
ii  libdb4.6         4.6.21-16         Berkeley v4.6 Database Libraries [runtime]
ii  libdb4.7         4.7.25-9          Berkeley v4.7 Database Libraries [runtime]
ii  libdb4.8         4.8.30-2          Berkeley v4.8 Database Libraries [runtime]
ii  libdb4.8-dev     4.8.30-2          Berkeley v4.8 Database Libraries [development]

That's just a matter of using a different soname whenever something
changes in a backward incompatible way. Even for cases where the soname
is fixed 'for political reasons' aka 'glibc', the issue is supposed to
be handled transparently via symbol versioning.