DESTDIR setting fails

[kevinburke1]

Hi, I am trying to build Ruby for packaging with fpm, with these two steps:

PREFIX=/usr/local/ruby ./install.sh MAKE_INSTALL_OPTS="DESTDIR=/tmp/ruby" ruby-build "2.7.0" "/usr/local/ruby"

This installs Ruby to e.g. /tmp/usr/local/ruby/bin/ruby, so far so good. However, RUBY_BIN is set to /usr/local/ruby/bin, not /tmp/usr/local/ruby/bin, so anything that calls it, for example verify_openssl, also fails, because the binary is in the wrong place.

It would be nice to have a global DESTDIR setting that modifies RUBY_BIN (which appears to be unsettable from the outside) and also modifies MAKE_INSTALL_OPTS.

[mislav]

Hi, where did you find documentation for DESTDIR and what did you think it did? We don't support DESTDIR at all in ruby-build.

[mislav]

Ah, I see now! Is the problem that you successfully passed DESTDIR to the ruby make process, but subsequent steps inside ruby-build weren't aware that this changed the location of the ruby executable?

I wonder what would be the right approach to solve this. I'm not sure if we could reliably parse MAKE_INSTALL_OPTS to learn about DESTDIR.

[kevinburke1]

I'm not sure if we could reliably parse MAKE_INSTALL_OPTS to learn about DESTDIR.

Agreed. I think the better approach would be to add a configuration option and then append to MAKE_INSTALL_OPTS if set. I could put together a patch if you want.

[mislav]

Sounds good! Also note that the PR should add the config option to the table in the README.

[kevinburke1]

Here's the patch I have right now:

https://github.com/meterup/ruby-build/commit/74cad0e158e65c67c3d08ed2e88984451020a217

The $RUBY_BIN post-verify scripts fail unless we set RUBYLIB as e.g.

LD_LIBRARY_PATH=/tmp/releases/2.7.0/usr/local/ruby/lib RUBYLIB=/tmp/releases/2.7.0/usr/local/ruby/lib/ruby/2.7.0/:/tmp/releases/2.7.0/usr/local/ruby/lib/ruby/2.7.0/x86_64-linux/ /tmp/releases/2.7.0/usr/local/ruby/bin/ruby -e "puts 'hi'"

I'm not sure how to programmatically get out x86_64-linux or whether it's a good idea to set it.

[kevinburke1]

Another option would be a way to figure out how to remove e.g. the verify scripts that run after Ruby is compiled.

[eregon]

Looking at this issue I'm confused, why is the prefix (the second argument of ruby-build) not enough, what's the point of using DESTDIR?

[ashafer01]

@eregon I'm in need of this feature because I need to build ruby in one unprivileged environment to produce an artifact to install into several other environments, in order to eliminate unnecessary repeated builds.

Per https://www.gnu.org/prep/standards/html_node/DESTDIR.html :

Prepending the variable DESTDIR to each target in this way provides for staged installs, where the installed files are not placed directly into their expected location but are instead copied into a temporary location (DESTDIR). However, installed files maintain their relative directory structure and any embedded file names will not be modified.

DESTDIR support is commonly used in package creation. It is also helpful to users who want to understand what a given package will install where, and to allow users who don’t normally have permissions to install into protected areas to build and install before gaining those permissions. Finally, it can be useful with tools such as stow, where code is installed in one place but made to appear to be installed somewhere else using symbolic links or special mount operations.

[mislav]

Hi, first of all, apologies to both @kevinburke1 and @ashafer01 for sitting on this for too long without a review nor a decision. Second, I'm doubly sorry that I am now changing my sentiment about this since my last comment, since I am no longer in support of this feature.

When I first gave this a green light, I thought that it would be relatively simple to shoehorn DESTDIR support into ruby-build and that it fits out project's philosophy. However, when I saw the amount of changes needed to make this happen, I'm not so convinced, especially since it might potentially introduce bugs into the normal (non-DESTDIR) mode of operation, and because the added code looks hard to maintain. Finally, I don't think anymore that this fits into ruby-build spiritually. If you need to package Ruby for an OS, I firmly believe you should download the source code, configure it, and compile binaries yourself instead of having ruby-build abstract parts of that away. As a package maintainer, one should strive to have the highest level of control over the build process, and introducing intermediaries like ruby-build into the process would just be a liability.

After all, manual steps to compile Ruby should not be that hard. They are roughly:

1. Download a tarball, extract it;
2. ./configure --prefix=/usr/bin
3. DESTDIR=/tmp/my-destdir make install

Should every Ruby user need to go through a similar manual process to install Rubies on their system? I don't think so, and that's why ruby-build exists to abstract this away. Should a package maintainer for Ruby go through this process every time? Absolutely, I now believe.