[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

awscli v2 dependencies (was Re: Next team meeting: 2022-11-09 20:00 UTC)



On Sun, Nov 13, 2022 at 09:51:52PM -0800, Ross Vandegrift wrote:
> Noah Meyerhans has continued the work packaging awscli v2.  We discussed the
> issues surrounding the current dependencies of aws-crt-python - upstream
> sometimes breaks api & abi compatibility without changing the soname.  For now,
> we decided to distribute static-only library packages to avoid breakage for
> consumers of the shared libs.
> 
> This allows us and others to proceed with using these libraries.  But folks
> outside of the cloud-team should avoid uploading packages that consume these
> libraries, or else be prepared to respond to broken interfaces.  For now we
> won't consider those to be bugs.  This will be documented in the packages.

So, some time has passed and I haven't managed to work on this at all.
Given the number of packages involved and the dependencies between them,
I'm not optimistic that we'll be able to package them all individually
as we discussed at the meeting.  In order to facilitate the packaging of
awscli v2, I'm inclined to fall back to my proposal from #966573 [1].
Essentially this would package aws-crt-python as a single package with
the C code as a private component, rather than broken out into
standalone packages.

I understand that there's other software that may want to take direct
dependencies on the C libraries, but as I don't see any of that being
actively worked on in terms of packages that'll be ready for inclusion
in bookworm, I don't think the unavailability of these packages will be
a significant blocker for anybody.

Of course, if anybody wants to take on more of the work to get the C
libraries packaged (and more importantly, shepherded through the NEW
process), and can commit enough time to respond to feedback promptly,
etc, please shout real soon, and we can coordinate.

> We've heard that upstream will eventually stabilize these interfaces.  So we
> hope this situation will eventually improve.

I had a conversation with some of the people working on this.  They're
aware of the issue but the effort to stabilize the ABI is nontrivial.
Since they currently break ABI compatibility regularly, they haven't
bothered versioning it at all, not seeing much value in a rapidly
increasing ABI number.

noah

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966573#131


Reply to: