[DRE-maint] Bug#972702: ruby-bundler: dependency resolution fails for compiled gems

[Antonio Terceiro]

On Thu, Oct 29, 2020 at 01:21:03PM +0100, David Rodríguez wrote:
> El 29/10/20 a las 13:14, Antonio Terceiro escribió:
> 
> > On Thu, Oct 29, 2020 at 11:17:59AM +0100, David Rodríguez wrote:
> > > Hi!
> > > 
> > > Just to clarify why I prefer the second solution, I think what debian does is shipping precompiled versions of extensions, so technically the gemspec shipped in the debian should include no extensions at all. This is something some upstream gems already do. Take, for example, google-protobuf. It has a precompiled version for linux: https://rubygems.org/gems/google-protobuf/versions/3.13.0-x86_64-linux. If we fetch and unpack this package, we can see it includes the prebuilt `.so` extension, but no extensions in its gemspec:
> > > 
> > > $ gem fetch google-protobuf
> > > Fetching google-protobuf-3.13.0-x86_64-linux.gem
> > > Downloaded google-protobuf-3.13.0-x86_64-linux
> > > 
> > > $ gem unpack google-protobuf-3.13.0-x86_64-linux.gem
> > > Unpacked gem: '/home/deivid/Code/playground/google-protobuf-3.13.0-x86_64-linux'
> > > 
> > > $ find google-protobuf-3.13.0-x86_64-linux -name '*.so'
> > > google-protobuf-3.13.0-x86_64-linux/lib/google/2.6/protobuf_c.so
> > > google-protobuf-3.13.0-x86_64-linux/lib/google/2.4/protobuf_c.so
> > > google-protobuf-3.13.0-x86_64-linux/lib/google/2.7/protobuf_c.so
> > > google-protobuf-3.13.0-x86_64-linux/lib/google/2.5/protobuf_c.so
> > > google-protobuf-3.13.0-x86_64-linux/lib/google/2.3/protobuf_c.so
> > > 
> > > $ gem unpack google-protobuf-3.13.0-x86_64-linux.gem --spec && grep extensions google-protobuf-3.13.0-x86_64-linux.gemspec
> > > extensions: []
> > > 
> > > I think the cleanest solution would be for debian to do the same thing.
> > Fair enough. Now that I think about it, extensions is supposed to be
> > a list of extensions that need to be built, so indeed dropping it from
> > the gemspec included in the Debian packages make sense.
> Yeah, that's exactly how I expect the `extensions` field to be interpreted.

On the other hand, our packages that already use the rubygems machinery
to install, already contain the gem_build.complete file:

$ dpkg -L ruby-byebug | grep complete
/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/extensions/x86_64-linux/2.7.0/byebug-11.1.3/gem.build_complete

----------------8<----------------8<----------------8<-----------------
$ cat > Gemfile
source "https://rubygems.org/"
gem "byebug"
----------------8<----------------8<----------------8<-----------------
$ bundle --local
Resolving dependencies...
Using byebug 11.1.3
Using bundler 2.2.0.rc.1
Following files may not be writable, so sudo is needed:
  /usr/local/bin
  /var/lib/gems/2.7.0
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
----------------8<----------------8<----------------8<-----------------
$ echo 'gem "ffi"' >> Gemfile
----------------8<----------------8<----------------8<-----------------
$ bundle --local
Could not find gem 'ffi' in any of the gem sources listed in your Gemfile.
----------------8<----------------8<----------------8<-----------------

So this is only a problem for the "old-style" packages that install their
stuff to vendor_ruby and don't install as gems:

$ dpkg -L ruby-ffi | grep gem.build_complete
(nothing)

and they are quite a few packages yet:

$ apt-file search vendor_ruby/ | grep '\.so$' | wc -l
164
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-ruby-extras-maintainers/attachments/20201029/942e2fd1/attachment-0001.sig>