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
| Filename | Size | Changed |
|---|---|---|
| 1.33.4.tar.gz | 0002740224 2.61 MB | |
| _link | 0000000124 124 Bytes | |
| ac_update-docutils.patch | 0000004330 4.23 KB | |
| aws-cli.changes | 0000208997 204 KB | |
| aws-cli.spec | 0000003314 3.24 KB |
Revision 209 (latest revision is 214)
Robert Schweikert (rjschwei)
accepted
request 1179724
from
John Paul Adrian Glaubitz (glaubitz)
(revision 209)
- Update to 1.33.4
* api-change:``auditmanager``: New feature: common controls. When creating custom controls, you can
now use pre-grouped AWS data sources based on common compliance themes. Also, the awsServices
parameter is deprecated because we now manage services in scope for you. If used, the input is
ignored and an empty list is returned.
* api-change:``b2bi``: Added exceptions to B2Bi List operations and ConflictException to B2Bi
StartTransformerJob operation. Also made capabilities field explicitly required when creating a
Partnership.
* api-change:``codepipeline``: CodePipeline now supports overriding S3 Source Object Key during
StartPipelineExecution, as part of Source Overrides.
* api-change:``sagemaker``: This release introduces a new optional parameter: InferenceAmiVersion,
in ProductionVariant.
* api-change:``verifiedpermissions``: This release adds OpenIdConnect (OIDC) configuration support
for IdentitySources, allowing for external IDPs to be used in authorization requests.
- from version 1.33.3
* api-change:``account``: This release adds 3 new APIs (AcceptPrimaryEmailUpdate, GetPrimaryEmail,
and StartPrimaryEmailUpdate) used to centrally manage the root user email address of member
accounts within an AWS organization.
* api-change:``firehose``: Adds integration with Secrets Manager for Redshift, Splunk,
HttpEndpoint, and Snowflake destinations
* api-change:``fsx``: This release adds support to increase metadata performance on FSx for Lustre
file systems beyond the default level provisioned when a file system is created. This can be done
by specifying MetadataConfiguration during the creation of Persistent_2 file systems or by updating
it on demand.
* api-change:``glue``: This release adds support for creating and updating Glue Data Catalog Views.
* api-change:``iotwireless``: Adds support for wireless device to be in Conflict FUOTA Device
Status due to a FUOTA Task, so it couldn't be attached to a new one.
* api-change:``location``: Added two new APIs, VerifyDevicePosition and ForecastGeofenceEvents.
Added support for putting larger geofences up to 100,000 vertices with Geobuf fields.
* api-change:``sns``: Doc-only update for SNS. These changes include customer-reported issues and
Comments 12
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
I do not see any harm in having an aws-cli-v2 package in this project. Once we have that we can then start conversations with various people if the bundling is acceptable for any distribution. Based on the results of that conversation we can then make a decision as to whether or not aws-cli package can move to be built with the v2 source or if they have to remain separate.
Thanks a lot for your Feedback Robert, appreciated. I spend a bit time to package aws cli v2 and it's dependency awscrt. Both build in my home project [1] on Factory, Leap and SLE on x86_64 and aarch64. I submitted aws-cli-2 to Cloud:Tools [2] and python-awscrt to devel:languages:python [3] as devel project for openSUSE Factory. I'm looking forward to help optimizing and maintaining the new packages.
[1] https://build.opensuse.org/project/show/home:wombelix
[2] https://build.opensuse.org/request/show/1173437
[3] https://build.opensuse.org/request/show/1173436