Bug#966573: progress packaging awscli v2
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
Reply to: