Hello everyone,
TL;DR: with gem2deb 0.23 in experimental you can tell dh_ruby to install
using the same layout as Rubygems by adding `export DH_RUBY =
--gem-install` to your debian/rules.
I have just uploaded to experimental gem2deb version 0.23, which
includes a --gem-install option to dh_ruby that will install
packages using the same layout as Rubygems, instead of the layout we
have been using in Debian since before Rubygems came into existance.
I would like your feedback.
Installation layout differences
-----------------------------------------------------------------------
The traditional gem2deb installed will install to the following paths:
/usr/lib/ruby/vendor_ruby
pure Ruby code
/usr/lib/<triplet>/ruby/vendor_ruby
native extensions
/usr/share/rubygems-integration/all/specifications
gemspec files for architecture independent packages
/usr/share/rubygems-integration/$RUBY_VERSION/specifications
gemspec files for architecture dependent packages, for each supported
$RUBY_VERSION
The new gem installer will install *everything that is listed in
.gemspec* to the following locations:
/usr/share/rubygems-integration/all/
for architecture independent packages
/usr/lib/<triplet>/rubygems-integration/$RUBY_VERSION/
for architecture dependent packages, for each $RUBY_VERSION
Problems being solved
-----------------------------------------------------------------------
Since packages installed with the new gem installed will look exactly
like their upstream counterparts look like when installed via Rubygems,
we would not need to handle the following issues anymore:
- Content outside lib/
We have been patching every package in which the code depends on stuff
outside of lib/, such as templates, configuration, etc etc. In these
cases, we needed to ship those in /usr/share/$package, and patch the
code that uses such content to look it up in /usr/share/$package
instead of somewhere relative to lib/
- Namespace issues in /usr/lib/ruby/vendor_ruby
Since /usr/lib/ruby/vendor_ruby is shared by all packages, we usually
have namespace issues there, specially for Rails-related packages
where Rails assumes that each installed package has its own isolated
lib/ directory, so it encourages library authors to override Rails
files such as generators (i.e. code that generated files in Rails apps
based on templates, such as library-specific configuration files, etc).
See #770251 for an example
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770251
Can anybody think of other things we usually need to patch because
upstream assumes the Rubygems installation layout?
How to use
-----------------------------------------------------------------------
- Install gem2deb 0.23 from experimental
- Add the following to debian/rules
export DH_RUBY = --gem-install
(in this version dh_ruby will use $DH_RUBY as an extra source of
command line arguments)
Pending issues
-----------------------------------------------------------------------
- currently READMEs, changelogs and license files are being duplicated
in the Rubygems directory, while on Debian they should be in
/usr/share/doc/$packages
- C source for native extensions is also being installed, and we
probably don't need that.
- <insert yours here after you give it a try>
The future
-----------------------------------------------------------------------
In principle, packages using this new installer will work just fine
together with our "traditional" packages.
I believe that this will immensely reduce the mismatch between Debian
packages and upstream, making it a lot easier for us, and make
everything work better together. I think that at some point this should
become the default, if not for all, at least for new packages.
I am looking forward to read your ideas about it.
--
Antonio Terceiro <terceiro@debian.org>
Attachment:
signature.asc
Description: PGP signature