Re: RubyGems in Ruby HEAD

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 ?

> The reality is that if people need a feature that isn't available using
> your packaging system, but it's available with another, they're going to
> install it. I was talking with someone last night who kept insisting
> that .deb is a "de facto standard" for Unix. Leaving aside the fact that
> the young man in question is *nuts*, .deb isn't a de facto -- or de jure
> -- standard, but it *can* be supported on other platforms by installing
> a program that understands .deb (e.g., alien). So if a FreeBSD user
> needs something that's only available as an RPM or a .deb package,
> they'll install the appropriate tools and then install the package.
> RubyGems is no different.
>
> > However, I had to provide a RubyGems package as some apps are now only
> > distributed as .gem and I needed gem to fetch the files and then build
> > the rpm. I have nothing against .gem for people wanting to use it in
> > their home, but I hope no Mandriva admin will use it system wide. I
> > like the libs and apps coming with metadata
> > (dependencies/versions/...) described in a standard way, but I
> > consider this should only ease the generation of rpm, maybe automate
> > it, not replace it.
> >
> > 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 would need :
- test the requirements on the real system
- maybe configure the files for the system without changing anything on it
- install to an empty destdir without running configuration scripts
- have a command to run configure/deconfigure/register/... hooks so
rpm can run them at install time on the client

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

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

But for sure, having a way to not duplicate what is done is the gem
and use it is the best way.

> >> 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, ...)