Rainer Weikusat <rainerweikusat@???> escribió:
> 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.
THIS is an example of how to do it properly. But you can not
(currently) version virtual packages.
Regards
Noel
er Envite
::
Re: [DNG] leveldb support proposal
