On Mon, Dec 04, 2017 at 10:38:35AM +0100, Cédric Boutillier wrote:
> Hi,
>
> I was thinking, maybe naively, that gem2deb could solve globally the
> problem with `git ls-files` instead of patching each and every gemspec
> using git.
>
> Running currently `gem contents --all` on my system is far from listing
> the files from all the Debian ruby packages installed on my system.
> Only those which are installed under /usr/share/rubygems-integration and
> some files from /usr/lib/ruby/2.3.0.
>
> Is it the expected behaviour?
AFAICT, gem contents takes the list of files, looks for then inside the
"gem directory" (which in Debian is
/usr/share/rubygems-integration/*/gems/$GEM-$VERSION/), and lists the
ones that exist there. With our old-style installation layout
(vendor_ruby), this will never work.
> Gem2deb could replace the files field in the installed gemspec with
> the list of files installed in the package.
>
> But if we don't care about the gem command knowing about the installed
> files, then we could just replace files field by an empty list.
>
> What do you think?
Packages using the Rubygems installation layout have this working out of
the box, so one way to fix all packages would be to convert all packages
to using the Rubygems layout. I wanted to make dh-make-ruby use that by
default for new packages at some point.
*But* the list of files that are installed is controlled by that `files`
field, so you have a chicken-and-egg problem there.
Now, with regard to the problem of us still needing to patch a lot of
packages to replace git ls-files with something sensible, I think we
could do better, e.g. we could rewrite the source gemfile before running the
build, and setting the `files`-related fields to something sensible,
such as variations of `Dir['**/*'].reject { |f| f =~ %r{^debian/} }`.
Attachment:
signature.asc
Description: PGP signature