Re: RubyGems in Ruby HEAD

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

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

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