On 8/9/20 4:59 PM, Anatoly Bashmakov via aur-general wrote:

Hello.

I need feedback on packaging ruby gems.

First, I don't think packaging every gem of the latest version makes a lot of sense. For development there are rvm/rbenv/etc that solve this problem. The only gems need to package (I think) are gems that are required by end-user applications. But such applications may require gems not of the latest versions. So, there are several options here.

1) Bundle dependencies in the application itself. I don't like this approach at all, since the package begins providing a lot of unnecessary gems.  Example: ruby-gollum-lib [1].

This package is in severe violation of PKGBUILD standards. It's bad enough when mysteriously complicated software only works with giant ruby-bundler envs installed in /opt. But under no circumstances should it be installing its own dependencies into /usr/lib/ruby/gems

2) Package dependency gems only of versions required by the application. For example, gollum-lib gem requires loofah ~2.3 (which means >= 2.3 and < 2.4). The latest version of loofah is 2.6.0. So naming package ruby-loofah of version 2.3.1 for gollum-lib may entails rightly flagging it as out of date.

Indeed, non-slotted packages might be needed by other software expecting up-to-date versions, so this is strictly inferior to option 3.

3) Packaging versioned gems. In previous example the package will be called ruby-loofah-2_3 (or something) and add "provides" in PKGBUILD. It is not forbidden by package guidelines (but not encouraged either) as far as I remember.

This is a suitable workaround if the package cannot be updated to use the latest version. But try to see if upstream can update their code to be compatible with the latest versions of their dependencies...

4) Not package ruby gems at all.

I don't like neither of these options, but I think packaging versioned gems is lesser evil.

What are your thoughts?

[1]: https://aur.archlinux.org/packages/ruby-gollum-lib/

-- Eli Schwartz Bug Wrangler and Trusted User