Adding Requests to the standard library [LWN.net]

Adding Requests to the standard library

Posted May 1, 2015 21:22 UTC (Fri) by dlang (guest, #313)
In reply to: Adding Requests to the standard library by Cyberax
Parent article: Adding Requests to the standard library

> It will work. If it is completely statically linked or bundles everything above syscalls.

it will also work if it uses standard libraries that maintain good backwards compatibility (glibc, X11, etc)

Adding Requests to the standard library

Posted May 3, 2015 21:15 UTC (Sun) by paulj (subscriber, #341) [Link] (18 responses)

So basically only ancient, athena-era X11 apps.

Newer stuff, GNOME-era on, you're sunk. You need virtualisation/containers to run your old apps on the specific distro they were compiled for.

Adding Requests to the standard library

Posted May 3, 2015 23:03 UTC (Sun) by lsl (subscriber, #86508) [Link]

It's really not as bad as you make it sound.

http://upstream-tracker.org/

Quite a few solid libraries in there. Of course, if you want your program to run on RHEL5 you can't use library additions introduced yesterday. That seems to be the actual problem in some cases instead of missing backwards compat. It's the same on windows though: if you use features introduced with Windows 8 your program won't run on XP.

Adding Requests to the standard library

Posted May 4, 2015 3:34 UTC (Mon) by dlang (guest, #313) [Link] (16 responses)

> Newer stuff, GNOME-era on, you're sunk.

I believe that I have seen just a wee bit of displeasure at Gnome for the changes that they make from release to release ;-)

But in any case, is this the fault of the distro or the Gnome developers/maintainers? They are the ones who choose to make it so that it's hard or impossible to have both old and new versions of their libraries on the same system.

Adding Requests to the standard library

Posted May 4, 2015 3:37 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (15 responses)

What's difficult about shipping the old GNOME libraries?

Adding Requests to the standard library

Posted May 4, 2015 3:48 UTC (Mon) by dlang (guest, #313) [Link] (3 responses)

my understanding is that the new versions use the same names as the old ones, so that if you want to install both, you have to rename one version (with the included hassle of changing everything that links to it to link to the new name)

I don't use Gnome, but I remember people complaining about this when Gnome 3 came out.

Adding Requests to the standard library

Posted May 4, 2015 3:50 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (2 responses)

> my understanding is that the new versions use the same names as the old ones

Do you have any specific examples?

Adding Requests to the standard library

Posted May 4, 2015 3:58 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

no, as I said, go back and look at the discussions around the time that Gnome 3 was released and all the people who wanted to use the old version, but couldn't.

Adding Requests to the standard library

Posted May 4, 2015 4:00 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

Those were discussions about whether it was possible to install multiple versions of binaries, not libraries.

Adding Requests to the standard library

Posted May 4, 2015 8:17 UTC (Mon) by paulj (subscriber, #341) [Link] (10 responses)

The old gnomemm library is difficult enough to ship that Fedora had to drop it, and along with that some (perfectly functional and very useful) applications stopped being available. E.g. referencer.

A container/chroot with the old libs is the easiest way to make that run (I tried building the old gnomemm myself from SRPMs - impossible due to build deps).

Adding Requests to the standard library

Posted May 4, 2015 10:55 UTC (Mon) by paulj (subscriber, #341) [Link] (9 responses)

Oh, and referencer is a free software app, with source. I spent 1.5 days going through it trying to update it to match the gnomemm → GLib/GTK+ changes (URI and GVFS stuff that moved to a 'similar but not quite the same' API in GLib), and still hadn't really made a dent of what was left. So I gave up and went with Zotero. That seemed less worse than relying on an app that needed fiddling with manually extracted old libs to keep running (and I'm happy with Zotero now).

ABI compatibility on desktop Linux - at least in the GNOME world - isn't even a joke.

Adding Requests to the standard library

Posted May 4, 2015 11:05 UTC (Mon) by paulj (subscriber, #341) [Link] (8 responses)

Oh, and I don't "blame" the GNOME people per se. It's sort of a wider failing. That the GNOME people have also been looking at doing their own distro-agnostic, package bundles suggests this too.

We need to get to a point where distros can guarantee forward compatibility. If a package installs on distro version N, it should install on all N+M, M>0.

Or, distros need to shrink to a core, and we look at higher-level ways of installing packages. As many of the programming languages already do for their library ecosystems - each differently though.

Adding Requests to the standard library

Posted May 4, 2015 14:33 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (7 responses)

> We need to get to a point where distros can guarantee forward compatibility. If a package installs on distro version N, it should install on all N+M, M>0.

That's backwards compatibility. Forwards compatibility is "compile on N+M and run on N". *That* is not possible without versioned symbols and something to tell the linker to blacklist certain versions of symbols so that only specific ones are used. The solutions here[1] are way too verbose and finicky for sane maintenance (so you just end up building on Debian Etch'n'half and hoping for the best).

Adding Requests to the standard library

Posted May 4, 2015 14:34 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Oops, forgot the link: http://stackoverflow.com/questions/8823267/linking-agains...

Adding Requests to the standard library

Posted May 4, 2015 16:09 UTC (Mon) by paulj (subscriber, #341) [Link] (5 responses)

Uh, yes, I mean backward compatibility.

Point being, if you can't take (say) a package for SpiffyDistro 16 and install it on SpiffyDistro 20, you don't have a system that is going to be generally useful for computer users - because it isn't stable enough for vendors to target it. It might be useful for some niche subset of users.

It doesn't matter how it's done, through containers or what not, but that needs to work, if todays distro model is to survive.

Adding Requests to the standard library

Posted May 4, 2015 18:01 UTC (Mon) by dlang (guest, #313) [Link] (4 responses)

The thing is that excluding things that depend on "Desktop Environment" libraries, most apps and their libraries do continue to work on newer versions of a distro (and are pretty trivial to get working on different distros), there are a few notable exceptions (openssl, Python 3.x changes are a couple of noticeable ones), but overall things work well.

It's when you have things start tieing in to the Desktop Environments that things are more 'interesting'. Unfortunately this does include a large percentage of GUI apps, but not all of them, some GUI toolkits are more stable than others.

Adding Requests to the standard library

Posted May 4, 2015 18:16 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (3 responses)

Again, which libraries are you talking about? libgnomemm vanished from Fedora because something lower down its build chain no longer built and nobody was willing to maintain it. The old binaries will still install.

Adding Requests to the standard library

Posted May 4, 2015 19:04 UTC (Mon) by paulj (subscriber, #341) [Link] (2 responses)

So why don't Fedora ship them then, if it's so easy to ship old libraries?

The end-user experience is that a perfectly good application disappeared.

Adding Requests to the standard library

Posted May 4, 2015 19:09 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (1 responses)

It didn't build, and packages that don't build end up getting removed.

Adding Requests to the standard library

Posted May 4, 2015 19:36 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

To be clear, I'm not arguing that this isn't a problem, just that the fault doesn't lie with the library authors.