gem1.9.1 doens't install executables on PATH

[Stefan Lang]

Binary package hint: ruby1.9.1

Package: ruby1.9.1 version 1.9.2.0-1

The included rubygems is configured with EXECUTABLE_DIRECTORY
set to /var/lib/gems/1.9.1/bin which is not on the users PATH by default.

This breaks expected and documented ruby gems behaviour,
especially installation instructions of numerous ruby programs.

Proposed solution:
Set EXECUTABLE_DIRECTORY to /usr/local/bin

[Zygmunt Krynicki (zyga)]

This has been debated over and over again.
/usr/local/bin was rejected because the packaging and filesystem policy clashes. I cannot offer any solution that would not raise all the objections from both sides.

BTW: would it be possible to solve the problem by instaling gems as is today and adding that directory to PATH the first time rubygems are installed?

[Lucas Nussbaum (lucas)]

There's no easy way to add a directory to PATH.

[Stefan Lang (langstefan)]

> This has been debated over and over again.
> /usr/local/bin was rejected because the packaging and filesystem policy clashes.

I've found these previous discussions:
https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/145267
and
http://fossplanet.com/f10/bug-448639-rubygems-fhs-compliance-debian-ubuntu-43888/

Where's the packaging and filesystem policy clash?

What's the purpose of /usr/local/bin if not for stuff like this.
This way gem doesn't affect apt installed software and vice versa.

[Zygmunt Krynicki (zyga)]

You can install gems from debian packages which _cannot_ put things into /usr/local/. You can also install gems directly. This would probably be a nightmare to maintain.

In my personal opinion the /var/lib path is broken too. The problem with the "language-centric" repositories and their client-side package managers is that they have to clash with the system packager. They clash for filesystem namespace (apt-get/yum install foo vs pip/gem install foo) and clash for semantics (one-vs-more-than-one version at a time).

A suboptimal solution (at least for ruby where you _want_ to install many versions of one thing at a time) that would still improve the situation could make this:

* work on rubygems to have a debian-connector that automatically keeps the debian metadata in sync (so packages installed via gem behave the same as packages installed with dpkg, except that they don't pick up non-ruby dependencies).
* install things into /usr/lib and /usr/bin

If anyone is willing to try doing this (the same debian-connector, or perhaps dpkg-connector) could be used for python and pip as well) feel free to start discussing and drafting this here. I was considering doing this a while ago.

[Zygmunt Krynicki (zyga)]

I used some confusing statements in my previous comment. I would also like to clarify some things.

1) Package installed with domain-specific manager like gem or pip becomes "debian" package at installation time. It can be removed and upgraded using either of the managers (with appropriate hooks/triggers ensuring that the process behaves properly). Dpkg would have all the proper meta-data about packages (like files, md5sums and so on). The only meta-data that would be partially missing is native dependencies that debianized packages of domain-specific packages sometimes have.

2) Packages with more than one version could be mangled into different packages inside debian. This is suboptimal but would work. It _probably_ will be hard to do generate proper virtual packages so that I can install libfoo-1.2.3 and still get libfoo1 and libfoo1.2

3) Packages that already have been debianized might need to conflict with the domain-specific packages. I can see a lot of potential issues here (domain specific package becomes many debian packages for example, slightly different names, debian-specific patches). This is a big topic for research.

[Stefan Lang (langstefan)]

> You can install gems from debian packages

Something is either a gem or a deb package. A Ruby package installed via apt should not show up as RubyGem and a Ruby package installed via gem should not show up as deb. A cleanly written Ruby program that requires a library doesn't care with which package manager it was installed.

Keep debs and gems separate. They satisfy different needs that cannot be integrated into a single solution.

View gem as just some program that happens to write to /usr/local/bin. No deb integration. Nowhere does RubyGems advertise deb integration. That would be an extra (that would IMHO, be more problematic than useful). So why not fix the basics (executables in PATH), before even thinking about extra functionality?

[Zygmunt Krynicki (zyga)]

Stefan, there is no semantic difference between a gem and a deb package. It's just a difference of implementation details. From users point of view they both install, remove and upgrade things. By making both play well with each other you improve the user experience. That said, I agree that the connector idea is a separate topic.

While I agree there is a problem it's not a simple problem to solve. The discussion on installing to /usr/local seems to have stalled. There are security concerns with installing things with gem/pip and other similar programs with a way to override something on the default path. What is interesting (and quite worth discussing) is why pip can do it but gem cannot. Is pip any more secure than gem today?

[Stefan Lang (langstefan)]

> it's not a simple problem to solve

I disagree. The current state is this: Installation instructions recommend installing RubyGems from source because Ubuntu's is broken. This rubygems installed from source in combination with a Ruby installed from apt will cause gem to write executables in /usr/bin.

What again is the argument against setting EXECUTABLE_DIRECTORY to /usr/local/bin? It's more standard conforming than the current /var path. It's simply the administrator (sudo) installing an executable in /usr/local/bin, which is standard practice.

Ubuntu doesn't modify other software to prevent writing to /usr/local/bin, why pick out rubygems, whose users are developers, not technology averse end users?

[Zygmunt Krynicki (zyga)]

I'll try reopen the discussion about gem policy.

Despite all debian security concerns there is a very vocal ruby community that shuns our patches and we should work to make the situation better.

[Zygmunt Krynicki (zyga)]

A few people discussed this issue on #ubuntu-devel and we came to the following conclusion:

1) We should coordinate this change in both Ubuntu and Debian.

2) We should change the install location for gems to /usr/local. We still have to patch upstream source as the default install location (/usr) would clash with debian packages and is not safe. Using /usr/local will yield all the benefits (is on default path, can override system packages, does not clash with system packages) without introducing any significant new issues. This would also be consistent with the way we handle python's pip tool that is similar in spirit to gems.

3) We need to apply this change to both rubygems 1.8 and ruby 1.9

4) We need to have migration path. Currently a few options are still possible but we believe that simply moving all the data to /usr/local and dropping a symlink in the old location would be sufficient.