On Fri, Nov 04, 2022 at 05:37:21PM +0100, Bastian Blank wrote: > > > Are you sure this library can have a 1 as ABI? Can you please reproduce > > > the ABI stability promisses? > > Allegedly upstream has recently committed to proper SONAME and ABI > > management in support of efforts to get these packages accepted into > > Fedora. I'll see if I can find meaningful evidence of this... > > The SOVERSION was set two years ago: > > https://github.com/awslabs/aws-c-common/pull/702 > > So some more information would be nice.
According to the person who handled the Fedora review for aws-c-common (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2049379), davdunc had indicated he'd take care for SONAME management until upstream gets things worked out. I haven't been able to get in touch with davdunc yet to confirm this. Given the number of packages involved, though, I expect it'll take a while for everything to have a properly managed SONAME. Given that, I see a few alternatives: 1. We package aws-crt-python with all the aws-c-* packages included in a single source package. Given that upstream maintains this structure in a single repo using git submodules and that their build system supports it directly, it appears to be the way they expect the package to be consumed. 2. We package the individual aws-c-* dependencies but only ship static libraries, and handle them as standard buid-deps for aws-crt-python. 3. We manage the SONAME versions ourselves until upstream does it for us. 4. We ignore awscli v2 and continue shipping v1. I actually prefer #1 and suggest we do that. My reasoning is: 1. It's well supported by upstream, 2. It prevents other packages from picking up the aws-c-* packages as dependencies before they expose a stable API/ABI, 3. It is simple to split out the submodules into standalone packages one-by-one as their interfaces stabilize. 4. It's quite simple to implement What do folks think of this idea? noah
