Amazon Web Services Command Lin Interface
The AWS Command Line Interface (CLI) is a unified tool to manage your AWS services. With just one tool to download and configure, you can control multiple AWS services from the command line and automate them through scripts.
- Devel package for openSUSE:Factory
-
1
derived packages
- Links to openSUSE:Factory / aws-cli
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout Cloud:Tools/aws-cli && cd $_ - Create Badge
Refresh
Refresh
Source Files (show unmerged sources)
| Filename | Size | Changed |
|---|---|---|
| 1.32.31.tar.gz | 0002645915 2.52 MB | |
| ac_update-docutils.patch | 0000001284 1.25 KB | |
| aws-cli.changes | 0000134671 132 KB | |
| aws-cli.spec | 0000003314 3.24 KB |
Latest Revision
buildservice-autocommit
accepted
request 1161724
from
Factory Maintainer (factory-maintainer)
(revision 206)
Factory Maintainer (factory-maintainer)
(revision 206)
baserev update by copy to link target
Comments 10
Hello,
Is there a release plan for aws-cli-v2 yet?
https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html
best regards, Matthias
Yes, I was planning to do the switch within the next days.
So, I just wanted to upgrade aws-cli from v1 to v2, but it turns out that upstream is now bundling botocore and s3transfer into the source code which is against the policy that we have in openSUSE (and most other Linux distributions).
https://github.com/aws/aws-cli/pull/6494
I will stay on v1 until I have verified that we can unbundle botocore and s3transfer again.
Why though? I see from the repos of botocore and s3transfer that they're under apache-2.
This has nothing to do with the license but how the world, i.e. openSUSE and most other distros are set up to track security issues. That is one reason distro packaging policies do generally not want dependent code to be bundled. While rpm has some features to declare such bundled code I do not think all the tracking code that looks for CVEs has evolved yet to handle the bundling.
If we unbundle, i.e. we pull the bundled dependencies back out of the source tree then we have to carry patches that handles the "import" statements, I have not looked at how much work that will end up being and we force the SDK, i.e. botocore onto the update schedule of aws-cli v2. Meaning if botocore moves forward and aws-cli does not we cannot provide a newer package of botocore either.
I am only aware of 1 feature that is in v2 that is not supported in v1, that's sso.
Last but not least those that absolutely feel neglected by us still building v1, can build their own package or pull form AWS and get v2.
Thanks for your thorough answer and effort to maintain this package. I'm a bit new to openSUSE so that's why I'm asking. Personally I think aws should take this responsibility of distributing the cli to different distros instead of using the bash script and forgetting about updating it forever.
Hello guys. Is this still valid on 05/2023, so no chance to have aws-cli-v2 on openSUSE?
I haven't checked on the current state of the upstream sources for a while. I can have a look and see if things have improved.
@guinuxbr what in the v2 version do you need that is missing?
@glaubitz @rjschwei I'm happy to invest the time to package it and create a request.
But before I do that, I would like to clarify the statement about bundled dependencies.
My understanding is that this policy changed 1st June 2023 (https://en.opensuse.org/openSUSE:Bundled_software_policy).
Fedora has a pretty similar rule (https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling). Package
awscli2is available since May 2023 (https://src.fedoraproject.org/rpms/awscli2) in Fedora.With the public available information I have, I don't see a reason why there can't be a awscli2 package in openSUSE? Maybe to give customers choice it could be a separate one. That way it's up to the individual to decide if awscli (v1) or awscli2 fits there use-case.
The features in aws cli v2 that are not backported are listed here: https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration-changes.html#cliv2-migration-changes-features