Scoperunner needs to be versioned using SOVERSION

[Michal Hruby]

If we want to provide compatibility with scopes compiled against older versions of the library, we need to properly version also scoperunner, not just the library itself. Otherwise the runner would link against latest version of libunity-scopes and the loaded .so against an older version, and things would be pretty likely to blow up.

[James Henstridge (jamesh)]

There is a little more to it than just including ABI version in the scope runner executable name: the registry would also need to know which scope runner each scope needed (since we'd need to run the version of scoperunner that matched the library version the scope was linked against).

This could be done via the ScopeRunner configuration field Pawel added, but I'm not sure what it should be set to exactly.

Another alternative would be to encode the ABI version in the scope's shared library name.

[Michi Henning (michihenning)]

When the scoperunner initialises a scope, it checks the version. If the version of the scope doesn't match the scoperunner's version, the scoperunner bails out with an appropriate message.

But I agree that we have a problem as it stands because, if we deploy a new version of our library, all existing scopes will break until they are recompiled and and redeployed.

Here are some thoughts:

We would need to keep multiple copies of the scoperunner around. Not sure what the implications are for packaging and installing upgrades. If someone upgrades the scopes infrastructure from, say, 1.0.0 to 2.0.0, would it be possible to leave the previously-installed libs and scoperunner binary behind? Or would we include the version 1.0.0 binaries and library in the 2.0.0 release?

If the latter, how would we manage this for our build environment once we start working on version 2? Exactly how would we ensure that older binaries and libs either get recompiled from the then-current sources and get included in the 2.0.0 package? How would cmake cope with this?

Or would we keep the old binaries around as binary blobs somewhere inside the source tree to be added to the 2.0.0 package? How would this interact with multi-arch?

For the scoperunner itself, we could have a "wrapper" scope runner whose job it is to identify what version is needed by a particular scope and then exec the version-specific scoperunner accordingly.

How does the scoperunner know what version is needed? It could just load the shared lib for the scope, retrieve the version number, and then make a decision accordingly. This is somewhat expensive, but probably preferable to requiring the scope author to add a version number to the scope's .ini file. (I expect that doing this would turn out to be brittle and error-prone.)

There is also the issue of config files. Over time, we will certainly add new config items, and quite likely deprecate some. At the very least, the config machinery would have to tolerate unknown settings (which it does, currently, with a warning).

Opinions?

[Michi Henning (michihenning)]

I've created a branch that mangles the major version number into the scope's create function symbol, so we can detect if a scope is ABI incompatible by looking through the symbol table (instead of having to call ScopeBase::start()). This change is ABI incompatible (but source code compatible), so scope source code doesn't need to be changed.

lp:~michihenning/unity-scopes-api/add-version-to-create-function-name

For now, only the major version number is checked, until we get around to dealing with bug #1320026.

We still have the int that is returned from ScopeBase::start(). With the version mangled into the create function name, forcing the scope author to return the version from start() is redundant really. It seems it would be cleaner to change start() to have void return type.

Opinions anyone? I'm thinking that we could lump this in with Pawel's recent incompatible changes.

Please speak up, I don't want to merge-propose this half-baked.

[Michal Hruby (mhr3)]

Yes, let's drop the now-redundant int return from start().

[Michi Henning (michihenning)]

Fixed with commit 386 on devel.

[Michal Hruby (mhr3)]

Nope, to fix this fully we need to actually support running scopes with multiple SOVERSIONs.

[Michi Henning (michihenning)]

Ah, OK, yes :-)

But I think with the recent change to mangle the so version into the create function name, we have at least the relevant hooks in place to make this possible.

[Michal Hruby (mhr3)]

Indeed, but until we can run a scope built against libunity-scopesX at the same time as one linked against libunity-scopes(X-1), spawned by the same registry, I don't consider this done.

[Michi Henning (michihenning)]

Yes, I agree! Sorry for going of half-cocked there…