Re: RubyGems in Ruby HEAD

On 9/23/05, Pascal Terjan <[e-mail]> wrote:
> On 9/23/05, Austin Ziegler <[e-mail]> wrote:
>> Okay. All of those can be solved by wrapping .gems in RPM packages if
>> there's a feedback hook (see #15 on the TODO list that I provided).
>> This includes database synchronization.
> Sorry but I subscribed only yesterday and I can't find this list in
> the archives. Where could I find it ?

http://www.ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-core/5882

That's my list. There are references to other lists on that thread, but
I can't seem to find Why's original list and Chad's update to that list.
Mine is orthogonal in many ways to their lists. (Mine is more focused,
as well, on #3 of Why's list, IIRC.)

>>> A one-direction solution is what PHP's pear does : provide a
>>> "register" command to tell the pear system that we have installed
>>> the soft without using it. Then pear knows that the lib is there,
>>> the version, the provided files, ... and if people want to install
>>> additionnal stuff using pear the dependencies will be met. The issue
>>> in in the other direction, when people install with pear something
>>> which is needed by a rpm...
>> I would be opposed to a "register" command in RubyGems. The better
>> solution would be for repackagers to *use* RubyGems internally for
>> Ruby .gem packages and acknowledge that it was installed that way.
>> You've got custom install/uninstall scripts available, so why not use
>> them?
> The tests I did did not allow me to do what is required for a clean
> rpm package but I did not follow gem developpment for quite a long
> time

What I'm talking about would be a matter of something that could be
added moving forward.

> What I would need :
> - test the requirements on the real system

This is the responsibility of the "superior" packaging system (e.g.,
RPM, Debian, Ports, Portage, etc.). IMO.

> - maybe configure the files for the system without changing anything
>   on it
> - install to an empty destdir without running configuration scripts

Please elaborate on this. I'm not sure that this is actually something
that is necessary on a RubyGems system, since each gem is confined to a
directory structure that is independent of the main structure. Much ado
has been made in the past about doing transactional installs, but the
very structure of RubyGems (with one exception) is such that everything
is in its own directory and is therefore essentially a transaction in
and of itself. That one exception is the installation of binary stubs
(e.g., ldiff on Diff::LCS), and I *think* that those are being installed
in such a way as to not include version numbers any longer (they assume
the use of the latest version unless a --version parameter is provided).

> - have a command to run configure/deconfigure/register/... hooks so
>   rpm can run them at install time on the client

RubyGems *already has this*. There's a missing callback component, and
the list of enhancements that I've suggested will make it far friendlier
to *all* repackagers, but it already has it. Consider a mythical
foo-1.0 package that is only available as a Gem. Now, you want to
provide foo-1.0 as an RPM on your system. If foo-1.0 is pure Ruby (which
is most of them), then absolutely *all* you need to do is package
foo-1.0.gem inside of your foo-1.0-1.rpm that then calls:

  gem install ./foo-1.0.gem
    or
  gem uninstall foo-1.0

One of the suggestions I made (#14?) included the ability to lock
installs with a secret key known only to the packaging system:

  gem install ./foo-1.0.gem --packager-lock <signature>
  gem uninstall ./foo-1.0.gem --packager-unlock <signature>

Or something like that. Even that could be avoided if there's a system
specific callback in RubyGems. The packagers for Ruby and/or RubyGems
would create callback scripts, say:

  register-install.rb
  register-uninstall.rb

These scripts would perhaps intercept the RubyGems commands submitted by
the user and invoke the appropriate RPM commands on Mandriva.

RubyGems remains neutral, RPM uses RubyGems, and the user can safely use
either one without even thinking about it. The scenario is only slightly
more complex when it's a gem that contains a compiled extension, but
I'll discuss that below.

The gem database, so far as I can tell, is actually the directory of
gemspecs that are installed on the system.

> This is needed to have the rpm containing the installed files (and
> config script) and not the gem itself.

And what I'm saying is that the RPM shouldn't contain the installed
files; it should contain the .gem itself. IMO, RubyGems should not
suppport any other configuration.

> There are various reasons to do that : being able to search for a
> missing file in the repository db, being able to check integrity of
> installed files, being sure that uninstall removes (almost)
> everything, not needing to store the .gem on the system while it is
> not needed anymore after installation, ...

I think that RubyGems has a lot of that support already, and RubyGems
*will* remove *everything* related to the gem on uninstall, so far as I
can tell.

>>>> Why not? Many Ruby libraries have no non-Ruby code, so there's no
>>>> difference between a 'binary' and a 'source' version of them. Plus,
>>>> surely it's possible to mark that (say) openssl-ruby depends on
>>>> having a C compiler and openssl-dev?  If necessary for policy
>>>> reasons, mark it as a 'source' rather than a 'binary' package.
>>> And then people will install a compiler on their server to ease
>>> exploits ? or remove the compiler after each install ?
>> Sorry, but that's a red herring as RubyGems already supports
>> precompiled binary gems.
> They need to be available for the given distro (with the right lib
> versions, ...)

This is why I have on my list "a dead simple way of packaging binary
gems". In this way, repackagers could continue to use the infrastructure
of RubyGems and provide precompiled gems for their platforms. The
developer wouldn't need to; the repackager could, if they don't want
general users building the code.

-austin
--
Austin Ziegler * [e-mail]
               * Alternate: [e-mail]