-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Please improve packaging & distribution #30
Comments
Strongly concur with @peterwwillis . To say that the Debian packaging on this repository is non-compliant is a vast understatement. Also, the hosting of the Debian archive s3 is inappropriate. If this was an effort to "dog-food" your own services, I can understand, but without (SIGNED) package repository indices, I can't leverage |
It would be great if AWS could provide the bare binaries as well. I hope it shouldn't be a big problem thanks to Go. And according to this post here the OS packages already include a binary. |
I'm interested in packaging this for NixOS/nixpkgs but there are a few issues that others have already pointed out -- #23 about not building on currently supported versions of Go (fixed by #11 or #33), no dependency pinning/verification, some unresolvable imports (#1), no release signing (not critical for my specific use case, but really desirable for a security-sensitive tool generally). Currently it looks like the only feasible option to get this working would be to maintain a fork, which I'm not really interested in 🙂 I'd love to see these issues fixed in this repository so it's at least possible for community members to build packages for their own Linux distributions as needed without forking. (Of course, it'd be even better to see a wide variety of distributions supported officially by Amazon directly, but I'll take what I can get!) |
Holy moly this is embarassing. How is Ubuntu with systemd not supported? It's bad enough I had to use snap to install the agent on an Ubuntu server, but now I can't even install this plugin without figuring out how to compile from source? |
AFAIKT the systemd unit and init script in the package is just some generated boilerplate that does absolutely nothing. There is no service / background process. I was just scripting a little bit and it seems to be enough to extract To get the package version from the invalidly named
Extract the binary:
I'm not sure what the packaging achieves here, as it really has non-standard install location, unwanted service setup, broken changelog, .... 🤷 |
@jvtm you're absolutely right, the only thing you need out of the given Debian archive is the executable binary. The packaging contributes little to the organization of the content. It even confuses matters with its mismatched versions and do-nothing service unit. |
Hello AWS, this is not possible a simple issue like this has been opened since Dec 30, 2021 ! Why don't AWS just put a public repository with all the tools for major linux distro and that's it. This is a pain for a lot of people. Come one AWS push the extra miles like you alway say ! Best! |
This request is for AWS to hire someone to fix the packaging for its various customer-exposed tools (like this project). Specifically it's intended for the upper-management and executive team that should be overseeing customer experience.
The Linux packages are pretty bad. No dependency on AWS CLI, obscure package name, non-standard file paths, faulty install scripts, unnecessary install-time dependencies, and no official support for any particular Linux distro other than Ubuntu Server (presumably because that's what the developers use). No CI (seriously? it's built right into GitHub!), no matrix of target platforms, no packages submitted to distributions, no generic installer script.
Not only that, but the downloads and source code don't have any cryptographic signatures. If the packages were distributed by a package manager, you'd at least get signatures for free. But since there's not even a checksum listed on the AWS docs, the user has no way of knowing if their package or download has been tampered with. You're asking your customers to expose their internal networks to administrative users that have downloaded tools whose security is literally impossible to verify.
These are not senior-level tasks requiring rare talent. A core AWS team dedicated to open source could liaise with project teams like this one to standardize things like CI, linting, packaging, installing. Hiring for this shouldn't be challenging, even with the current job market - people all over the world do this for fun in their spare time.
Considering that AWS makes $59 Billion dollars a year, and has something like 100,000 engineers, there's no justification for the state of things. If this is how AWS manages their public tools, I can't imagine how shoddy the internal ones are. And judging on the number of bugs in the new Web Console, there's a much larger organizational issue at play (which doesn't bode well for AWS' stock price). All Azure needs to do to start eating your lunch is make better packages, and all the Linux nerds (like myself) will start opting for Azure first. The irony!
The text was updated successfully, but these errors were encountered: