Re: RubyGems in Ruby HEAD

Marc Dequ竪nes (Duck) wrote:

>mathew <[e-mail]> writes:
>  
>
>>Are you actually intending to produce Debian .deb packages for every Gem?
>>    
>>
>
>Yes we DO for most of them.
>How do you think the thousands of source packages are maintained in
>Debian ? Automagically ?
>  
>

I asked if you were intending to produce Debian packages for *every* 
Gem. You replied that you produce packages for *most* of them. In other 
words, you didn't really answer my question.

Are you intending to produce Debian packages for *every* Gem?

If the answer is "no", then I'd rather you didn't produce packages for 
*any* of them. Reason being, I want to be able to request any Gem X and 
get its dependencies Y and Z automatically, without then having two 
dependency management systems fighting each other.

I should mention that I'm speaking as someone who uses Debian more than 
any other Linux distribution.

>Rubygems only target systems with no existing packaging system, and
>forget the whole world is not doing this way.
>

No, RubyGems targets systems running Ruby. As far as I know, it runs on 
(and is targeted to run on) all Ruby systems, not just the ones that 
don't have any existing packaging system.

>>I ask because coming from a Perl background, I've always found Debian's 
>>packaging of CPAN libraries to be incomplete enough to be problematic.
>>
[...]

>That's what RFP (Request For Package) is for. I know this is a pain when
>something is missing and you need it AT ONCE, but everything needs a
>start and i did not find so many perl things waiting, last time i
>checked the user requested softwares.
>  
>

If you intend to package everything, you ought to be following the 
stream of code releases added to the repository and packaging them--I 
shouldn't have to request something.

If it's something very new or I need the very latest release, then I 
might need to put out a RFP, but in general if you're packaging 
everything, any stable package ought to be there. And again, if you're 
not packaging everything, I'm afraid I don't want to use your packages.

>A Perl Team was created and organized and the situation has much
>improved.
>

Possibly; but to pick a random trivial example, File::Cat doesn't seem 
to be packaged, and that was released to CPAN in 1999.

>i don't think such a reply Austin did would bring ppl to continue contributing to Ruby at
>all.
>

Well, it nearly made me stop, but it's not like Debian doesn't also have 
its fair share of experts who drive away newcomers. In fact, I'd almost 
say that Debian was notorious for it.

For my part, I'm in the interesting position of actually caring about 
both sides of this argument. I use Debian every day, and I write some 
Ruby code most weeks. So be assured that if I seem harsh, it's not 
because I don't care... I just think that a useful resolution of the 
issue is going to require that both sides budge from their current 
positions. Debian will need to accept that APT is not the only packaging 
system that needs to be supported on Debian systems, and Ruby will need 
to accept that changes must be made to RubyGems so that it can be 
integrated with APT.

> Indeed not considering our problems would lead to the same
>starting situation with Ruby, because motivated ppl will soon leave the
>place and work for another project if we continue facing a silent wall
>or a wall saying "i don't care".
>  
>

I really don't see lack of packaged RubyGems in Debian causing anyone to 
abandon Ruby, any more than the lack of properly packaged CPAN libraries 
has caused people to abandon Perl. In fact, 
<URL:http://www.cpan.org/ports/> recommends against using binary 
packages right at the top of the page, and every Perl book I've seen 
points people to CPAN for their library needs, not to their Linux 
distribution. (The exception being Perl for Windows books which plug 
ActiveState's stuff.)

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

I think maybe you should poll a few Debian users who are Perl and/or 
Ruby developers before assuming too much. Take a look at what happened 
with Rails -- people didn't say "Oh, Rails doesn't work on Debian, 
Ruby/Rails must be no good"; rather, they put up pages saying "Debian's 
Ruby is deficient, here's how to install the latest Ruby and RubyGems so 
Rails will run."  Same for Mac OS X.

>>The solution I would like to see would be the one taken by Gentoo for 
>>CPAN--provide a wrapper which incorporates the language's packaging 
>>system in the Linux distribution's packaging system. With Gentoo I run a 
>>script naming a CPAN package, and it builds a portage package for that 
>>CPAN package (or downloads the pre-packaged Portage package if one 
>>exists). That way, both Portage and CPAN agree about what's installed.
>>    
>>
>
>Most distribution are precompiled ones, so this cannot apply.
>

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.

It seems to me dh-make-perl described at 
<URL:http://wiki.debian.net/?PerlFAQ> is a partial solution along these 
lines. The main problem with it--aside from it being for Perl--is that 
it leaves it up to the user to remember to check if there's a maintained 
Debian binary package first, before building one from the repository. 
I'd have thought that problem was fairly easily solved.


mathew