release 18.4.0 changed SONAME and broke compatibility about gmmlib HOT 12 CLOSED

Why? Softwares are allowed to change soname, that’s why it’s versioned!

from gmmlib.

changing soname is an absolute last thing and very expensive for all your downstreams.

Now linux distributions, like Intel's Clear Linux, will need to keep two packages, one with the old soname and one with the new soname.... you basically just doubled our package maintenance cost for this package. I also assume that this upstream project will keep providing security fixes for the old SONAME for at least 3 to 5 years?

changing soname is changing the ABI, and admitting that you didn't know how to keep ABI.
Doing that once every 5 years, sure, stuff happens... but it's still a bad thing

from gmmlib.

Why the hell would someone need to keep two packages? Just recompile depending software against the new soname, eol. Linux distributions do that all the time, that’s precisely their job.

Some packages change ABI very often, some never. That’s how things are. I find it absolutely normal for a young project like this to change ABI.

from gmmlib.

from gmmlib.

No, compat libraries is not because of ABI changes, but API changes (we have openssl-1.0 because some software did not update their API use, not because they are ABI incompatible with new versions).

I don’t care if you have gmmlib in Clear Linux or not, though I would find it funny that Intel Clear Linux does not package Intel gmmlib because upstream changes ABI sometimes.

P.S.: BTW, I’m not a gmmlib dev, I’m ArchLinux maintainer for gmmlib.

from gmmlib.

The definition of a soname, and so too the definition of the ABI compatibility you crave, is that it is something which requires all applications linked to it, to rebuild their applications with no code changes or resulting changes in functionality. It is thus formally incorrect to claim that anyone needs to provide two packages for it.

API changes are an unrelated concern, although if you want to preserve API compat you can of course provide multiple interfaces within a library...

from gmmlib.

@fenrus75 do you have a lot of closed-source software provided exclusively as prebuilt binaries which link to external gmmlib shared libraries? Because this is the only reason you would need to worry about providing multiple ABIs.

from gmmlib.

from gmmlib.

If they are using their own closed applications, then I assume they have the source code and can rebuild it.

If they're using a contractor who enhances an open-source program, then the contract should require that they receive the source code which they paid for the development of, because that's just how contracted development works. Otherwise they're just asking for trouble on so many levels -- who tosses their source code in the garbage after they build a one-time binary? What happens if they need further improvements and the original contractor didn't bother to retain the source code, or else went out of business/switched industries?

In the worst-case scenario they're purchasing the use of software from a vendor, but the corporate purchase, bizarrely, does not include the right to the source code for customization/auditing purposes. In this case, I would highly recommend that said software not rely on fragile things like external libraries that may or may not be installed, may or may not go out of style in the computing industry, and yes, may or may not change ABI over the years. There is a very easy fix for this, that makes everyone happy: use static linking.

This is a complete non-issue.

from gmmlib.

I still think that they need to care about their users and bump ABI only when absolutely necessary. They jumped 4 versions in one release, that should not happen.

from gmmlib.

also this library has a strong dependency with other open source libraries that have not communicated their support for this new ABI.

from gmmlib.

Hi,
Thanks for highlighting various aspects w.r.t ABI maintenance. We appreciate all the inputs. We will try to incorporate the same. However, new feature or product sometime results in unavoidable compatibility break which will be the utmost thing for us to do with no other alternative.
Since current version is the stable ABI, I am closing this issue.

from gmmlib.