Debian released aws-sdk-core has no version file about aws-sdk-ruby HOT 8 CLOSED

Reported https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028285

from aws-sdk-ruby.

We don't own or control the debian released version of the SDK. You can always get the latest from RubyGems.org using bundler.

from aws-sdk-ruby.

We don't own or control the debian released version of the SDK

Unfortunately I was unable to open an issue at https://salsa.debian.org/ruby-team/ruby-aws-sdk-core, where this is maintained. @vivekkj123 seems to be the maintainer on the Debian Ruby Team. Vivek, can you look into this issue so it can be closed here?

You can always get the latest from RubyGems.org using bundler.

Unfortunately that's not the case. The point of using the debian bundled system package is to be able to rely on unattended upgrades for security fixes, and not rely on Rubygems at all. For many of our systems, it is not possible to download gems from Rubygems.

from aws-sdk-ruby.

I would not at all depend on system ruby or system ruby gems for any kind of development. What is your use case with Ruby and the SDK? You should strongly consider using a Ruby version manager like rbenv or chruby, and bundler, to manage your application.

I would see if you can find a way to report this to the debian team.

from aws-sdk-ruby.

I would see if you can find a way to report this to the debian team.

Yes, that's the next step. I hope that tagging Vivek on GitHub is sufficient, but if they don't respond, I'll message the mailing-list.

You should strongly consider using a Ruby version manager like rbenv or chruby, and bundler, to manage your application.

We absolutely don't want this (for the use case at hand). Whilst I run 6 different versions of ruby on my own machine and use bundler every day, it does a particularly bad job on much security-reserved eco systems. We started out with our own Rubygems mirror (which we could secure in-house), but bundler will not receive unattended upgrades to installed gems, which system packages do. More elaboration below.

I would not at all depend on system ruby or system ruby gems for any kind of development.

Cross posted from the shrine issue:

TL;DR: security

Linux distributions in general are capable of downloading gems from Rubygems, but just like how many enterprises will not download JavaScript packages from NPM but rather from their own packages registry (usually because there is a SecOps team involved or to protect against yanking / pollution / phising / etc.), one can use debian to install packages as system gems.

On Debian systems, especially in production, you normally have one ruby version and one version per package. This creates friction when developing applications (less packages to pick from, sometimes being stuck with old version that don't have the feature you want), but you gain a lot.

1. Installing through apt-get means you'll always get compatible packages and security backports (even through unattended-upgrades) which is great for production systems. On many of our production servers, we cannot download from rubygems at all.
2. Installing through apt-get means that on the same Debian version (current stable is called bullseye), you'll have the exact same upgrade path when you move to the next version. This means that we need to figure out upgrades for each gem only once, and can then codemod 100% of our applications and libraries, greatly reducing the cost to upgrade to the next version.

There are plenty of people who use Debian in conjuction with:

• self built ruby
• multiple ruby version
• rubygems (e.g. via bundler)

There are also plenty of people however that strictly adhere to the packages from debian.

The way we make shrine work is by vendoring those. Because you always keep your dependencies to a minimum (thank you!!) this is extremely easy for us to do, and allows us to use non-debian packages where an author has ensured it's not a dependency hell. Unfortunately, aws-sdk-* instead that easy to vendor. Vendoring does increase the time to upgrade and adds a requirement to periodically do manual security updates. The more gems in a dependency tree when vendoring, the more painfull that is.

That said, whilst I am happy to discuss various way of running production and production-like environments, that's not really why I opened the issue. I appreciate the debian package is not managed by AWS :). I hope that by reporting this here, other people with similar issues won't need to look much further.

I'll close this, as it's unlikely the AWS team would pick this up, but feel free to respond and I'm happy to chat ;)

from aws-sdk-ruby.

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

from aws-sdk-ruby.

Debian ruby team provides support for ruby and rubygems shipped in Debian. You can report bugs via email like any other package - see https://bugs.debian.org for howto report a bug. Salsa is used only as version control system.

from aws-sdk-ruby.

@pravi thanks a million! I'm following the bug report there.

It wasn't easy to find that bug tracker from the package maintenance or salsa pages, even though it's easy to find from the main site. TIL.

from aws-sdk-ruby.