Re: RubyGems in Ruby HEAD

On 9/23/05, Pascal Terjan <[e-mail]> wrote:
> On 9/22/05, mathew <[e-mail]> wrote:
>> Marc Dequ鈩es (Duck) wrote:
>>> We packagers are also users, and we also speak for our amount of
>>> users, and there is no way ppl can be treated like Austin did. If
>>> you want Ruby out of Debian/Mandriva/RedHat/..., then go ahead.
>>> Software maintained by ppl taking only care of their own wishes
>>> considering users in a such Marillat-style should not be packaged or
>>> even used.
> packaging most of the Mandriva ruby libs and apps I step in the
> discussion. I really was not pleased when gem was introduced, as
> having several non consistent database is bad and not easy to handle.


> There are various reasons why I don't want users to use gems:
> - Won't know all the versions of software the will be using when
>   asking for support.
> - Distribution updates won't update software not handled by rpm
>   (inclding security updates)
> - Installing a ruby app with rpm won't be able to check for needed
>   libs using rpm dependecies mechanism, so we'll have to drop all
>   dependencies on ruby libs in ruby packages. Then people without
>   internet connexion will have to guess they have to install the rpm
>   by hand as gem cannot be used.
> - Installing ruby apps with gem won't be targeted to the given
>   distribution and won't have nice integration like menu entry (in an
>   existing menu section).

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.

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?

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

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