Rainer Weikusat <[email protected]> escribió:
Noel Torres <[email protected]> writes:Let's forget what is NOT important "Ivan J." <[email protected]> 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
bin4suoQ1wpzh.bin
Description: Clave PGP pública
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
