Broken ABI in networkmanager-qt

[Lamarque Souza]

On Tue, May 17, 2016 at 8:36 AM, Harald Sitter <sitter at kde.org> wrote:

> On Tue, May 17, 2016 at 11:06 AM, Jan Grulich <jgrulich at redhat.com> wrote:
> > Hi,
> >
> > we decided to drop WiMAX support in nm-qt when it's compiled against NM
> 1.2.0,
> > but this seems to break binary compatibility when nm-qt was previously
> build
> > against older NM version. I didn't realize this before that this could
> happen
> > and now I'm not sure how fix that.
> >
> > We could either:
> > 1) Revert the change removing WiMAX support, but that would break ABI
> > compatibility one more time.
> >
> > 2) Keep it as it is and let packagers know about this problem and ask
> them to
> > rebuild everything using nm-qt (plasma-nm, plasma-workspace) in case they
> > already have NM 1.2.0.
> >
> > What do you think is a better option?
>
> I am not sure how 1) would be an issue, or how it would break ABI
> again for that matter.
> If you add the relevant ABI back you are doing an ABI addition on top
> of the effectively new ABI, and adding things generally is a binary
> compatible change to both the original ABI (which would be back again)
> as well as the new semi-broken ABI as it would simply expand to again
> contain the removed ABIs. That said 1) is the better option. If one
> has built on top of nm-1.2, binary compatibility would be restored as
> the previous ABIs are back. If one hasn't built on top of nm-1.2,
> nothing would change and it would be as though the binary incompatible
> change never happened.
>
>
I agree with Harald here. manager.h is the only affected public header. You
just need to re-add the five wimax related methods with an empty
implementation and it should work. Fortunately, none of those methods are
virtual, so adding them does not break ABI.


> 2) would imply that we disregard the frameworks ABI stability promise
> which probably wouldn't be very nice. This option would also at the
> very least require a so-version bump to communicate the breakage
> properly.
>
> HS
>

No ABI will be broken by re-adding those methods. Again, if any of those
methods were virtual then re-adding them would indeed break ABI.


Lamarque V. Souza

http://planetkde.org/pt-br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160517/294ff5a3/attachment.html>