Some unreliable predictions for 2015

Posted Jan 16, 2015 11:51 UTC (Fri) by hitmark (guest, #34609)
In reply to: Some unreliable predictions for 2015 by dlang
Parent article: Some unreliable predictions for 2015

Much of the problem goes away if just the package managers could tolerate to have multiple versions of the same lib installed. versioned sonames exist for a reason...

Some unreliable predictions for 2015

Posted Jan 16, 2015 12:41 UTC (Fri) by anselm (subscriber, #2796) [Link] (7 responses)

I don't see why that would be a problem. On my Debian system I have multiple versions of, say, libreadline, libprocps and libtcl installed at the same time, in each case from separate packages, so the support seems to be there already.

Some unreliable predictions for 2015

Posted Jan 16, 2015 15:44 UTC (Fri) by cortana (subscriber, #24596) [Link] (6 responses)

This doesn't do what you think it does.

$ ls -l /lib/x86_64-linux-gnu/libreadline.so.{5,6}
lrwxrwxrwx 1 root root 18 Apr 27  2013 /lib/x86_64-linux-gnu/libreadline.so.5 -> libreadline.so.5.2
lrwxrwxrwx 1 root root 18 Jan 13 03:25 /lib/x86_64-linux-gnu/libreadline.so.6 -> libreadline.so.6.3

Looks promising at first glance, but what if my application wants libreadline 5.1?

The SONAME is not strongly tied to the version of the library, but to the compatibility level.

Some unreliable predictions for 2015

Posted Jan 16, 2015 15:56 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (5 responses)

Then someone goofed. Either you're either depending on unspecified behavior (which should be un-exported if possible), or a soname bump was missed upstream between 5.1 and 5.2.

Some unreliable predictions for 2015

Posted Jan 16, 2015 16:19 UTC (Fri) by raven667 (subscriber, #5198) [Link] (2 responses)

I think it is true that there are a ton of library ABI breaks where the soname isn't changed because many library authors don't know when the changes they make break it, they just recompile which hides a lot of issues. Distros like Gentoo and tools like OBS rebuild applications when a library dependency changes even if the soname is the same for exactly this reason, they wouldn't bother to do this if the soname was a reliable indicator of compatibility.

Some unreliable predictions for 2015

Posted Jan 16, 2015 17:45 UTC (Fri) by peter-b (guest, #66996) [Link] (1 responses)

So we have a perfectly adequate system that some people don't use properly, in fact. This is news?

Some unreliable predictions for 2015

Posted Jan 16, 2015 18:55 UTC (Fri) by cortana (subscriber, #24596) [Link]

No, we have an inadequate system that is only useful as long as upstream developers, downstream developers and distributors never make mistakes.

Some unreliable predictions for 2015

Posted Jan 16, 2015 18:56 UTC (Fri) by cortana (subscriber, #24596) [Link] (1 responses)

BTW, what happens if I actually need libreadline.so.4?

Some unreliable predictions for 2015

Posted Jan 16, 2015 21:22 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Either bundle or ask for that version to be packaged. Or provide it in your repo (since you're not likely to have such a package shipped by Debian itself without them handing back patches to update it).

Some unreliable predictions for 2015

Posted Jan 16, 2015 13:55 UTC (Fri) by cesarb (subscriber, #6266) [Link]

> Much of the problem goes away if just the package managers could tolerate to have multiple versions of the same lib installed. versioned sonames exist for a reason...

It's not that simple. Suppose a program is linked against library A which in turn is linked against libpng2, and that program is also linked against library B which in turn is linked against libpng3.

Now imagine the program gets from library A a pointer to a libpng structure, which it then passes to library B.