On 27 April 2017 at 14:37, Aaron Conole <[email protected]> wrote: > Hi Joe, > > Some stream-of-consciousness thoughts follow, sorry if it's a bit > disconnected.
Thanks for the thoughts! > Joe Stringer <[email protected]> writes: <snip> >> * Backport the fix and modify current, for example for 2.7 to use "8" as the >> "current" number. This would however conflict with the upcoming 2.8 >> release, >> so the "current" number would need to be modified to something else for >> that >> release. Result for users of libopenvswitch would be that the programs fail >> to dynamically load, because the libtool library version indicates that the >> newly updated OVS library is incompatible with the version that their >> application was compiled against. This is nicer than the previous >> option. > > The neat thing with this solution, though, is it doesn't break existing > applications by installing the software. The older libopenvswitch bits > are still available at 2.so.7, but it means a disconnect between > openvswitch version, and the library naming. True. Maybe this is the best from that perspective. Note that it's also possible that say, branch-2.6 and branch-2.7 need the ABI-breaking change, so we'd have to allocate one of the CURRENT numbers for each of those, then ensure that master is on something different. And obviously we'll have to change the CURRENT number each time we prepare a new minor release. >> * Attempt to find an alternative workaround, for instance by developing a new >> set of patches which disable functionality that triggers the bug, or by >> attempting to fix the underlying issue in a fundamentally different manner >> from the way it is fixed on master. This includes risk as the changes will >> not receive pre-release testing through developers running the code from >> the >> master branch. > > Agreed here, but we can try to mitigate this risk - possibly with > improved tests. It won't beat having lots of diverse soak time, but at > least it will be something. > > That said - I don't know what the right answer is. Maybe this is the > reason to have the long-term support distinction. Maybe the policy is > that for LTS releases, we actually promise NEVER to break ABI, and > instead figure out a more complicated backport that allows applications > to rely on a stable ABI (even if the api has to change). Just > brainstorming ideas. For what it's worth, non-LTS releases don't often get more than one update so there's less opportunities for the ABI to break. >> In the past, developers have not paid particularly close attention to changes >> to lib/*.h header files. Bugfixes which change these have been applied to >> master (this is OK), then backported to branches 2.6 and 2.7 without >> attempting >> to avoid changes to the header files (this is in contrary to the policy >> above). >> As such, there has been ABI breakage between v2.6.0...branch-2.6, and >> v2.7.0...branch-2.7. > > To this end, I've got something quickly cooked up. I'd like to > integrate it with something - maybe travis - do you think it's > worthwhile? > > https://gist.github.com/orgcandman/95c3129f677be0483daac437853c4071 > > At least we'd be aware that we are going to 'break' something, and can > plan accordingly. This sounds interesting. I tried it out, and made a few general adjustments to work in my environment - thanks! https://gist.github.com/joestringer/2c65d33565ec66d515a055299f58eac0 >> In this particular case it appears that if the issues are to be fixed on >> v2.7, >> then changes to include/openvswitch/*.h are necessary, and therefore we >> should >> export this ABI breakage through the libtool "current" number. There is >> currently no method to do this cleanly, as the libtool "current" number is >> tied >> to the OVS minor release number. >> >> This series proposes to change the name of the libopenvswitch-X.so.Y.0.Z >> library to become libopenvswitch-X.Y.so.CURRENT.0.Z, where X, Y, and Z >> correspond to the OVS release number, for example 2.7.0; and CURRENT is the >> libtool current number, which would begin as 0 for every libopenvswitch-X.Y >> release, and would be incremented whenever backwards-incompatible changes are >> introduced. The policy would remain that we make first efforts to avoid >> changing the "current" libtool number within an OVS release series; and if >> this >> is not viable or possible, developers may submit ABI-breaking changes along >> with an update to this "current" libtool number. >> >> If this is reasonable, I would also seek to backport this to branch-2.7. > > I'm not sure how that works in libtool - I'd need to look at the > documentation. It doesn't sound unreasonable, though. > >> I don't have a good understanding of the impact of such a change on >> libopenvswitch users, so I would welcome anyone building applications upon >> this >> to voice their feedback. My main concern is that if it's common to symlink a '/usr/lib/libopenvswitch.so' -> '/usr/lib/libopenvswitch-X.Y.so' and people just link -lopenvswitch then the libtool 'current' number is not going to be different, so maybe that just breaks at runtime? _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
