[ANN] RubyGems 0.9.5

[Austin Ziegler]

It's became very obvious to me who the anti-debian zealot is. You may
not use it or even care about it, personally I could care less if Ruby
was supported on Windows at all but that wouldn't cause me to lobby
against making allowances for it's support.

I'm anti-Debian-meddling. Not anti-Debian. (I use and recommend Ubuntu
regularly. The Debian Ruby packages, however, are a complete nightmare
to be avoided at all costs.)

Windows is a special case only because there's not typically a
compiler (but RubyGems should do more for environments that don't have
a compiler, because I don't necessarily *want* a compiler installed on
a production Ubuntu server, thank you VERY much).

You'll also note that what special support has been added to RubyGems
for Windows beyond a reasonable minimum was added through patches
offered by people affected by the problems. Plus, the Windows support
for Ruby is entirely community-provided, whereas Debian wants to be a
one-stop package repository. Well, they're failing the Ruby community
badly.

You want to fix RubyGems on Debian? Quit your bitching and offer some
damned patches already. Just remember that some of those patches have
to go to the Debian maintainers. Probably most of them.

I see no reason that Eric Hodel or anyone else should fix your problem
for you just because you choose to use a package that's *broken on
purpose* by the OS maintainers. I'd say the same thing if Apple had
done something similar. Microsoft isn't involved in making packages
for Windows Ruby.

The RubyGems team isn't perfect, but what they're providing is a
*Ruby* facility. If your OS isn't up to snuff, then it's up to you to
either not use what your OS provides or to get your OS up to snuff.
Nothing less, nothing more.

I just wish Debian users would stop bitching about this and *do* something.

-austin

 

[Austin Ziegler]

Using environment variables to override locations makes sense for end
users but not for base system configuration. Either using a file in
rubylibdir or a value in rbconfig both seem like excellent choices. Or
better yet using all these methods in an ordered evaluation seems the
best choice.

Disagree re: environment variables. There are exactly two environment
variable schemes that have to be patched:

export FOO=bar
set FOO bar

This can be done with /etc/profile or whatever the equivalent for csh
is. (On Solaris there's an even better place in /etc, but I can't
remember what it is.)

Patches for a rubylibdir support file would be good to offer to the
RubyGems team.

The one thing I keep sticking on is how do you handle 'gem update
--system'

Assuming that RubyGems is installed initially through a a distro package
it obviously can't update it's self in place. I think the ideal
solution here is that RubyGems (through load paths) allowed for two
levels of installation.

Not good, won't work.

What I mean is if the Debian distributed RubyGems was initially
installed right along side Ruby but an 'update --system' caused it to
install the new version to some none-dpkg controlled directory (that had
load order precedence) everything would mostly work as expected.

Bad. Special case for a mere distro.

It's not a perfect solution. There's the potential for users to get
confused about which RubyGems is getting used but they can check using
'gem environment'.

Potential defined as near-100%.

Is this at all what Apples patch did? or was that just for the gem
location?

Just for the gem location. With instructions on how to update the
RubyGems installed on the system. In other words, Apple didn't expect
you to wait for an OS update to update RubyGems, and it doesn't have
fine-grained package management like most Linux distros (which is both
good and bad). Downside right now to the Apple approach is that it's
unclear what will happen if you upgrade to RubyGems 0.9.6 (doesn't yet
exist) but the next OS X system update has RubyGems 0.9.5. I'd hope
that Apple's software checks the difference, but nothing has been said
about that so far.

If Debian doesn't want you updating RubyGems outside of Debian --
which is acceptable if not desirable, disable system updates outside
of apt-get. Just stop bastardizing the rest of RubyGems and do it
right. Otherwise, Debian needs to be ready for people to update
RubyGems in the system location using RubyGems itself and handle that
correctly on future apt-get updates.

Having two copies of RubyGems isn't really going to be a good choice,
especially with RubyGems moving into core Ruby with 1.9.1.

-austin

 

[Eivind Eklund]

Bad. Special case for a mere distro.

"Distro" is a synonym for "operating system".

Saying "mere operating system" comes across to me as arrogant.
Actually, saying "mere" about ANYTHING that your discussion opponent
is talking about comes across as arrogant to me.

I think we'd get much farther with the discussions here if we kept the
negative comments about stuff to a minimum and instead looked at the
real problems and looked for solutions to them. As it is, your text
comes across to me as full of inflammatory attacks on everything in an
effort to defend the status quo. I hope you will choose to
communicate better than that, as I've previously seen a lot of
well-reasoned stuff from you, so I know you can.

Disagree re: environment variables. There are exactly two environment
variable schemes that have to be patched:

export FOO=bar
set FOO bar

This doesn't cover zsh (which is fairly mainstream), not to mention
bush, esh, osh, or other "weird" shells. Also, of the two cases you
covered, one is wrong, though that's easily fixed by changing "set" to
"setenv".

Environment variables as base configuration has a number of
significant flaws, and to the best of my knowledge generally isn't
supported by OS installer systems. They are meant for per user/per
invocation configuration. System configuration is done in files or as
executable changes (or in the case of Windows, through the registry).
Bastardizing general environment variables for it just creates
trouble.

There is another solution that might work for the Debian packagers, though:

Just use a wrapper script. Thinking about this, we've done this for a
number of things that use env virables as configuration in FreeBSD,
and it should avoid the present problem, assuming that RubyGems will
update the "real" executable and not the wrapper script. Of course,
unless RubyGems hook correctly into dpkg, there might be a checksum
problem on uninstall, and extra files might be left over.

Eivind.

 

[Marc Heiler]

"Having two copies of RubyGems isn't really going to be a good choice,
especially with RubyGems moving into core Ruby with 1.9.1."

This is provided that these distributions stick to the FHS and will
never change. Since they stick to this layout, and use their own package
manager anyway, why dont you let them sort out their own mess?
Self-contained Programs in a dir with versions inside is much easier and
cleaner from an admin perspective in 2007, and they could easily run
different versions of Ruby next to each other and switch between these
versions easily too.

 

[Marc Heiler]

"Hehehe, no intention to offend anyone, but I feel better manually
downloading and compiling ruby and installing rubygems than using apt-
get or whatever package managing solution the platform offer."

Totally agreed. I am glad to be not the only one to do this.

On crippled windows system, gem is however very nice and
straightforward. Debian i.e. never has to bother with Windows

 

[Trans]

The real problem is that the FHS is outmoded. Advances in file systems
and storage hardware are making it increasingly pointless to strictly
separate files based on usage concerns --packaging concerns are
becoming more important. And it's about time too, b/c it's a hell of a
lot easier to maintain.

T.

 

[Michael Greenly]

Not good, won't work.


Bad. Special case for a mere distro.

My goal is to make using Ruby seem normal from both a Ruby users and
Debian users perspective. This means the installation needs to happen
with system tools; 'apt-get install ruby rubygems' and from there it
just works like a Ruby user would expect. Including doing a 'gem update
--system'

After thinking about Eklund's response I think I agree that debian's
'rubygems' package should be a wrapper script with RubyGems treated as
data in /var/lib/gems.

This mostly works. Gems can be gems and what it does has no effect on
the dpkg managed files. Except that /var/lib/gems/bin is outside of the
$PATH. So a noob user who does 'apt-get install ruby rubygems; gem
install rake' and then types 'rake' at the command prompt is not going
to get what they expect.

One option is for the install of the 'rubygems' package to fix up the
path and add /var/lib/gems/bin. I'm not sure about Debain policies
regarding path modification with package installation but I do know
doing it is not necessarily as straight forward as it would seem.
Different runlevels and users have a different $PATH.

So for robustness I (personally) would like to see a 'gem run' command.
This would allow for 'gem run rake' . It's possible this could be
provided in the Debian wrapper but I think it would be nice for it to
universally be available so that scripts, tutorials, etc... could be
written in a single, sure to work, robust manner for all platforms.

 

[Ken Bloom]

Fact set two: Debian (1) modified RubyGems; (2) didn't submit any
patches; (3) made a particularly stupid modification; and (4) provided
nothing to help users upgrade RubyGems externally of the Debian
packages.

If you think that being able to upgrade RubyGems externally of the Debian
packages is a good thing, then you don't understand the philosophy of a
Linux package manager, and you deserve whatever breakage results from
your stubborn insistence on flouting the package manager.

gem update --system should be removed from distribution-provided packages.

--Ken

 

[Ken Bloom]

What Debian is doing is sensible. Your decision to use non-debian methods
to upgrade RubyGems (instead of waiting for apt-get to have the new
version) is what broke things. This is true of all distributions with
package managers. If you upgrade outside the packaging system, it will
break things.

My understanding of the FHS says that you are not allowed to install
software into /usr/lib, only Debian is allowed to do that. So a hand-
installed (even gem update --system) RubyGems must be installed in /
usr/local.

This would probably happen if running gem update --system to go from
0.9.4 to 0.9.5 still used the 0.9.4 rules for determining the path. (Does
anyone know if this is the case?) An upgrade from 0.9.5 to 0.9.6 would
then work correctly. (Subject to the caveat that one should not use Gem's
upgrade methods to upgrade if they installed from the package manager
originally.)

Because Debian added a hard-coded hack RubyGems to use /var/lib instead
of using GEM_PATH and GEM_HOME. I don't know why RubyGems is using
/usr/lib/ruby/gems instead of /usr/local/lib/ruby/gems, but I suspect
that Ruby's Config::CONFIG has been partially modified.

See /usr/share/doc/libgems-ruby1.8/README.Debian which says that Debian's
rubygems package respects your GEM_HOME environment variable if you set
it yourself.

Yes, it is regrettable that Debian didn't instead add GEM_HOME to /
etc/profile (or equivalent). In that case (other than the /usr/lib vs
/usr/local/lib problem) upgrading RubyGems would Just Work.

Adding GEM_HOME in this way would be badly broken from the distribution's
perspective. See http://lists.debian.org/debian-devel/1999/06/
msg00561.html

--Ken

 

[Ken Bloom]

Hardly... in all package managed systems /usr/lib belongs to the package
manager. No other application should ever be mucking around in there.
This is not something unique to Debian based systems. It's just that
Debian users tend to be more more vocal about these policies.

The system package currently in Ubuntu for RubyGems just about gets it
right. They most likely should of disabled the 'system' update feature
so that it wasn't possible to do what I did.

Please file a bug in the debian bug tracking system
([email protected]) requesting that this feature be disabled.

--Ken

 

[Ken Bloom]

My goal is to make using Ruby seem normal from both a Ruby users and
Debian users perspective. This means the installation needs to happen
with system tools; 'apt-get install ruby rubygems' and from there it
just works like a Ruby user would expect. Including doing a 'gem update
--system'

After thinking about Eklund's response I think I agree that debian's
'rubygems' package should be a wrapper script with RubyGems treated as
data in /var/lib/gems.

This mostly works. Gems can be gems and what it does has no effect on
the dpkg managed files. Except that /var/lib/gems/bin is outside of the
$PATH. So a noob user who does 'apt-get install ruby rubygems; gem
install rake' and then types 'rake' at the command prompt is not going
to get what they expect.

One option is for the install of the 'rubygems' package to fix up the
path and add /var/lib/gems/bin. I'm not sure about Debain policies
regarding path modification with package installation but I do know
doing it is not necessarily as straight forward as it would seem.
Different runlevels and users have a different $PATH.

They should follow the lead of Debian's version of CPAN and symlink the
binaries into /usr/local/bin, but I'm not sure they'd consider this (or
at least they need some help from the RubyGems end. See http://
bugs.debian.org/403407)

--Ken

 

[Ken Bloom]

Hardly... in all package managed systems /usr/lib belongs to the package
manager. No other application should ever be mucking around in there.
This is not something unique to Debian based systems. It's just that
Debian users tend to be more more vocal about these policies.

The system package currently in Ubuntu for RubyGems just about gets it
right. They most likely should of disabled the 'system' update feature
so that it wasn't possible to do what I did.

I have filed a bug in Debian regarding this. See http://
bugs.debian.org/452547

--Ken

 

[Ken Bloom]

It's completely wrong and completely *not* RubyGems responsibility.
RubyGems shouldn't be patching/diffing. Do you know of *any* program
that does that?

This problem isn't RubyGems problem. While I might agree that
environment variables aren't ideal (they're not), they are the way that
RubyGems works.

Don't like it and have a better idea? Provide patches. Patches that
would make RubyGems work around a patched version of RubyGems, though,
should be rejected with force.


The problem is that Mr. Greenly did something that shouldn't have been
allowed. It's not RubyGems responsibility to prevent that; it's the
Debian maintainers responsibility to disallow it if they're going to
incompatibly (and stupidly) change a package that they're maintaining.

-austin

I have filed a bug in Debian regarding this. See http://
bugs.debian.org/452547

--Ken

 

[Austin Ziegler]

If you think that being able to upgrade RubyGems externally of the Debian
packages is a good thing, then you don't understand the philosophy of a
Linux package manager, and you deserve whatever breakage results from
your stubborn insistence on flouting the package manager.

gem update --system should be removed from distribution-provided packages.

Then it's up to the distro-packagers to do that.

Which is what I said in other posts on the thread.

I personally *don't* use *anything* Debian provides for Ruby because
they get Ruby wrong on almost every level.

Of course, Debian could also handle RubyGems better by wrapping gems
in a .deb package and going *with* the flow instead of fighting the
flow. But I argued that when RubyGems was first released.

-austin

 

[Eric Hodel]

If you think that being able to upgrade RubyGems externally of the
Debian
packages is a good thing, then you don't understand the philosophy
of a
Linux package manager, and you deserve whatever breakage results from
your stubborn insistence on flouting the package manager.

gem update --system should be removed from distribution-provided
packages.

I agree.