Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1030530 > unrolled thread

Bug#972702: ruby-bundler: dependency resolution fails for compiled gems

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#972702: ruby-bundler: dependency resolution fails for compiled gems deivid <deivid.rodriguez@riseup.net> - 2020-10-29 11:30 +0100
    Bug#972702: ruby-bundler: dependency resolution fails for compiled gems Antonio Terceiro <terceiro@debian.org> - 2020-10-29 23:00 +0100

#1030530 — Bug#972702: ruby-bundler: dependency resolution fails for compiled gems

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.

[toc] | [next] | [standalone]

#1030608

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web