Bug#448639: +1 for /usr/local
Adam Jacob
As a systems administrator, having libraries appear in /var/lib/gems,
and binaries in /var/lib/gems/1.8/bin is incredibly confusing. When I
install a rubygem on a system, I know I'm stepping outside of the
bounds of Debian's purview - I'm not using apt or dpkg, and I'm
venturing into the world of external package management.
Unfortunately, the choice makes it so I loose on two fronts: my
expectation is that things will wind up in /usr/local (as that's what
happens when I use CPAN, pypi, or easy_install), but they don't.
Secondly, unless the maintainer of the application (rails, chef, etc.)
knows the current status of rubygems on Debian and warns me up front,
I have no way of discovering a-priori that the changes to my system
are in /var/lib/gems.
As an active member of the ruby community, I constantly have to caveat
that users on Debian will get a sub-par user experience if they use
the community standard distribution mechanism. Most often, our advice
is simply to install the upstream rubygems package from source on
every Debian system - so that the behavior they experience at least be
in line with every piece of documentation generated by the ruby
community. Unfortunately, this has serious drawbacks - Debian policy
exists for a reason, and it makes the user experience better. In this
case, it makes it significantly worse. The reputation within the
community is widely that rubygems on Debian is "broken".
As a developer of a popular application built with ruby (Chef,) we
actively maintain and support packages built specifically for Debian.
I think it's clear to everyone that this should be the preferred path
for installation on a Debian machine - it ensures compliance with the
policy, and a smooth and predictable user experience. In this case
we're talking about what happens when an administrator explicitly
decides to take another route - just like when they use CPAN or pypi.
The reasonable thing to do here is to give them the experience that
they expect, while still keeping the base system clean for the future
- and to me, that means /usr/local.
The comments raised about the possibility of rubygems that install
binaries that replicate common system utilities is true of any outside
package management system, or any random tarball installed on the
system. We don't alter CPAN, or tar. Additionally, many rubygems no
longer even ship with setup.rb, and even fewer will as we move to 1.9,
where rubygems is a standard part of ruby.
Please make the defaults be /usr/local. At the very least, make the
Gem binary path be /usr/locall/bin.
Adam
--
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: ad...@opscode.com
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Daigo Moriwaki
Adam Jacob wrote:
> policy, and a smooth and predictable user experience. In this case
> we're talking about what happens when an administrator explicitly
> decides to take another route - just like when they use CPAN or pypi.
I have little idea on CPAN or pypi culture. Are unsigned packages (i.e. no
infrastructure checking packages consistency) common on CPAN or pypi? Don't CPAN
or pypi users have no security concern?
Regards,
Daigo
--
Daigo Moriwaki
daigo at debian dot org
Adam Jacob
> I have little idea on CPAN or pypi culture. Are unsigned packages (i.e. no
> infrastructure checking packages consistency) common on CPAN or pypi? Don't CPAN
> or pypi users have no security concern?
They do not have any kind of signing, as far as I know. In all cases, they have basic security schemes primarily at the point at which maintainers upload packages.
When end users install a gem, they take the responsibility for understanding the contents. It truly is no different than installing a source tarball in that regard.
Thank you for being open minded and willing to engage on this topic, Daigo, and for the work you put in to making ruby work well on debian.
Adam
Joshua Timberman
Hash: SHA1
I agree with Clint and Adam. While I certainly know how to set my PATH, I still install RubyGems from source on Debian (and Ubuntu) systems because the default package behaves in a way contrary to what I expect.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
iEYEARECAAYFAkx59EQACgkQO97WSdVpzT1uCwCgkm3Trf2Uj3B/Z60GhLQUINFr
tvEAn1AP5ySIlJb0hK7pmsvb4kAveikC
=/mcb
-----END PGP SIGNATURE-----
Darrin Eden
Jeffrey Hulten
--
Jeffrey Hulten
Principal Consultant at Automated Labs, LLC
je...@automatedlabs.com 206-923-8246
Scott Kitterman
The comparison (at least for Python, I'm not familiar with the others) isn't
really correct (for Debian/Ubuntu, I don't have other systems to check this
on). If I'm using the standard upstream packaging tool (distutils) it
installs in /usr/local, but in a Python specific directory so the exact concern
people have expressed about Gems is avoided.
Scott K
Aigars Mahinovs
>> Please make the defaults be /usr/local. At the very least, make the
>> Gem binary path be /usr/locall/bin.
>>
>> Adam
>
> The comparison (at least for Python, I'm not familiar with the others) isn't
> really correct (for Debian/Ubuntu, I don't have other systems to check this
> on). If I'm using the standard upstream packaging tool (distutils) it
> installs in /usr/local, but in a Python specific directory so the exact concern
> people have expressed about Gems is avoided.
>
Actually easy_install also installs run scripts from Python eggs (if
there are any) and those get installed into /usr/local/bin by default.
--
Best regards,
Aigars Mahinovs mailto:aiga...@debian.org
#--------------------------------------------------------------#
| .''`. Debian GNU/Linux (http://www.debian.org) |
| : :' : Latvian Open Source Assoc. (http://www.laka.lv) |
| `. `' Linux Administration and Free Software Consulting |
| `- (http://www.aiteki.com) |
#--------------------------------------------------------------#