From: Pascal Terjan Date: 2005-09-23T15:41:21+09:00 Subject: Re: RubyGems in Ruby HEAD On 9/22/05, mathew wrote: > Marc Dequ�nes (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 ?