[Rubygems-developers] Repackaging vs RubyGems (RubyGems TODO)

Austin Ziegler halostatue at gmail.com
Fri Sep 23 09:00:07 EDT 2005

On 9/23/05, Warren Seltzer <warrens at actcom.net.il> wrote:
> Repackagers etc. need to support non-programming users of Ruby
> software.

Nothing I've said denies this. What I *have* said is that the Debian
whinging has ignored the fact that Ruby (and therefore any packaging
solution for Ruby) has to support far more than just the little Debian
contingent out there. Frankly, if RubyGems were to pick just *one*
repackaging platform to pick, it wouldn't be .deb -- it'd be RPM.
Fortunately, the people who *are* developing RubyGems aren't platform
bigots and realise that a packaging solution for Ruby needs to satisfy
the same platforms that Ruby itself does, and that Ruby provides such a

Debian isn't the be-all-end-all of package management, and "relying" on
Debian repackagers when all they're going to look out for is their
users is a loser's game for the rest of Ruby's users and developers.

My stance on this is very simple: RubyGems needs to make it easy to
install packages in ways that continue to conform to the RubyGems
multiple version solution while also making it easy to conform to a
variety of configuration policies (e.g., the FHS neurosis). This will
avoid the equivalent of DLL-hell or the neverending upgrade cycle on
Debian et al.

Repackagers, on the other hand, should *use* the RubyGems installer
(like FreeBSD and Gentoo do) to actually install the .gem with the
configuration parameters set up to satisfy their packaging systems'
needs. This means allowing for separated arch-dependent and arch-
independent installs as well as a standard *versioned* DATADIR solution.
If the RubyGems team is going to add features to make DATADIR workable
and separated installation targets, then they should be used and trusted
to do their job properly. If repackagers *aren't* going to trust
RubyGems to do its job right, then most of this discussion is, IMO,

The repackagers are right now asking for special features to help them
with their jobs. I don't have a problem with special requests as long as
they don't amount to per-platform special support -- the long list of
features that I hvae said should be implemented to help this particular
series of problems should clearly indicate that, even to the most
zealous of Debian repackager. They've got to bend from their
philosophies here.

I've had people tell me that wrapping a .gem in a .deb isn't appropriate
because Debian isn't a source-based distro, but these people aren't
really thinking the problem through. RubyGems *already* supports the
installation of precompiled binary gems. While it should be made a lot
easier to create such precompiled gems, it is already possible to
support a binary-based distro like Debian.

I'm not against people who *want* to do:

  % apt-get rails

I *am* against RubyGems making single-platform concessions to simply
support apt-get while hanging the rest of the platforms out to dry --
including those without active repackaging efforts, or whose repackaging
efforts don't go to the neurotic level of subpackages (which is what I
generally consider RubyGems to be).

Fortunately, I think it's safe to say that the RubyGems development team
agrees that one-off platform support is a non-starter and that solutions
for Ruby are cross-platform.

I'll also add one more item:

15. Add the ability for RubyGems to communicate back with a system-level
    hook to say that a package was installed, removed, or updated so
    that other packaging systems can be informed of this fact.

It will be up to the Debian team to provide the necessary hook
implementation for Debian, etc. Not the RubyGems team.

> Think of all the employees in an insurance company or a call center
> re-configuring their machines.

Fortunately, it's usually the IT person that does that.

> So IBM and MS and Sun and their corporate users all have tools and
> policies to control configuration, and they aren't going to want to
> learn RubyGems to do that. RubyGems is probably only for developers
> and maybe power users. People providing toolsets to toddlers shouldn't
> be giving them a hi-power buzz saw, they'll only cut off their feet
> and start crying for Mommy.

I'm not sure what this has to do with anything. Frankly, apt-get is a
high-power buzz saw, too.

Austin Ziegler * halostatue at gmail.com
               * Alternate: austin at halostatue.ca

More information about the Rubygems-developers mailing list