RubyGems 0.9.5

Ruby
41

On Nov 22, 2:07 am, Michael G. [email protected] wrote:

install the new version to some none-dpkg controlled directory (that had
load order precedence) everything would mostly work as expected.

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’.

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

On any case, that wouldn’t work. Doesn’t packages contains a file
manifest bundled indicating which files are part of it? Also will
happen for ruby installed as package.

So, if you use gem system --update functionality, you brake your
package manager :stuck_out_tongue:

How users would remove it later if “they don’t like the updated
version”? what about duplication or you trying to find installed gems
in wrong places? (due the non-dpkg and dpkg’ed versions).

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.

–
Luis L.
Multimedia systems

Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

42

On 11/22/07, Michael G. [email protected] wrote:

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

43

On 11/21/07, Michael G. [email protected] wrote:

Austin Z. wrote:

I’d rather see RubyGems team spend its effort making sure that it
works well with MRI, XRuby, JRuby, Ruby.NET, IronRuby, etc. than
wasting their time trying to please Debian zealots who can’t be
bothered to think beyond their noses.
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 H. 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

44

On Nov 22, 2007 1:38 PM, Austin Z. [email protected] wrote:
[About stuff]

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.

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.

45

“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 :slight_smile:

46

“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. :wink:

47

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.

48

On Wed, 21 Nov 2007 10:28:03 -0500, Austin Z. wrote:

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

49

On Tue, 20 Nov 2007 09:29:31 -0500, Michael G. wrote:

debian packaged ruby with source installed gems.

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

50

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.

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.

51

On Tue, 20 Nov 2007 18:09:18 -0500, Eric H. wrote:

On Nov 20, 2007, at 08:18 , Michael G. wrote:

Austin Z. wrote:

On 11/20/07, M. Edward (Ed) Borasky [email protected] wrote:

  1. Work with the packages as supplied by your distro. 2. Don’t
    install the packages supplied by your distro – use upstream
    source and put things in /usr/local.
  2. Complain and whine to busy people who will blow you off. :slight_smile:
  1. Complain to your distro manager to be more sensible when it comes
    to Ruby. Look closely at what Apple did for good suggestions.

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.

This latest update some how decided to install rubygems to /usr/local
even though it was previously installed in /usr/lib

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.

and it moved it’s gem cache from /var/lib/rubygems to /usr/lib/
ruby/gems. Why?

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.

Now I realize the paticular oddities of this are not necessarily
RubyGems problems. I was using the Ubuntu patched version, but I’ve
looked at that patch and all it did was hardcode the GEM_HOME
environment variable to be /var/lib/rubygems.

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 debian-devel Jun 1999 by thread
msg00561.html

–Ken

52

On Wed, 21 Nov 2007 10:19:29 -0500, Austin Z. wrote:

environment variables aren’t ideal (they’re not), they are the way that

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

53

On Thu, 22 Nov 2007 11:51:54 -0500, Michael G. wrote:

had load order precedence) everything would mostly work as expected.

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

54

On Tue, 20 Nov 2007 09:29:31 -0500, Michael G. wrote:

debian packaged ruby with source installed gems.

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

55

On 11/23/07, Ken B. [email protected] wrote:

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

56

On Nov 23, 2007, at 07:10 AM, Ken B. wrote:

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.