From: Austin Ziegler Date: 2005-09-22T06:47:13+09:00 Subject: Re: RubyGems in Ruby HEAD On 9/21/05, Duck Marc Dequ�nes wrote: > mathew 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? That's your choice. I think it's silly, but that's just me. > Packagers too are willing to have a common solution for Ruby > distribution so as to simplify our work. Packaging similar things is > easier, and with a common system it would be even easier. In fact this > system should be flexible enought to allow GNU/*, *BSD, ... > distributions to integrate them cleanly and efficiently, what RubyGems > is currently not capable of. This is incorrect. RubyGems *is* capable of integrating cleanly and efficiently, and someone has already done this on FreeBSD. It might not be as clean and efficient as Debian purists want, but it *works*. Let me be very clear and note that even the Debian system of putting common data in a common place isn't necessarily ideal because I may have data that is very library-version-dependent (e.g., as with Ruwiki's version-dependent read-only wiki instance) or data that could be library-version-independent (e.g., as with the PDF::Writer included .afm files). And some might be the same until they change, which means they're both. How *do* you solve that problem? > Rubygems only target systems with no existing packaging system, and > forget the whole world is not doing this way. Should certain ppl then > be excluded? This is not only incorrect, it is arrogant. RubyGems targets *Ruby Platforms*. If you haven't yet, read the article that's on the front page of the RubyGarden website. RubyGems was developed without giving a single thought to OS dependent packaging system *and that is a feature*. It was written to solve CPAN-envy (after a fashion, and it does it much better, IMO) and a general packaging problem in any case. Frankly, it was also necessary because you know what? Most repackagers weren't interested in Ruby in any case. Beyond that, Solaris, AIX, and HP-UX use different packaging systems than RedHat and Debian -- and packaging for them is a lot harder, and there's no one who is really willing to do that. Making a single portable package system that is effective for ***RUBY PLATFORMS*** isn't only targeting systems with no existing packaging system -- it's being smart. (Can you point me to the railse package for HP-UX? Oh, you mean that it doesn't exist and that I have to download it and its dependencies from .tar.gz and install them? Right. *THAT* is as helpful as telling me to downgrade to Debian.) >> 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. For instance, last time I installed blosxom and some >> plugins, I had to go to CPAN for some standard libraries that weren't >> available as Debian packages. Once I have to go to CPAN even once, >> the value of repackaging the libraries in Debian format is lost--in >> fact, it becomes a liability. As others have already mentioned, you >> quickly end up with competing versions of the same library. > 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. Sorry, but that's a completely unacceptable answer. If I have a choice between a package that the author provides (who I can reasonably trust, probably) and something that *doesn't exist* unless I ask for it nicely, I'm going to go with the provided package every single time. This is the real world, folks, and RubyGems solves things that Debian folks apparently aren't willing to think about. >> I expect the situation will ultimately be the same with Ruby. Right >> now, it might be feasible to repackage everything from RubyGems to >> .deb; but I doubt that will continue to be the case, with an >> arbitrary number of people writing Gems, and a small number of Gem to >> Debian repackagers. > A Perl Team was created and organized and the situation has much > improved. 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". Frankly, I *don't* care about Debian issues. I don't have *time* to care about Debian issues. Aredridel has provided concrete suggestions, and there's a FreeBSD developer who just solved the problem. Debian has treated Ruby so badly that I care even *less* about Debian repackagers than I do other repackagers. Sorry, but the time for a "Ruby Team" was a while back -- maybe even before RubyGems started -- not right now. > Debian, Mandriva, RedHat, and the like, have got plenty of users, > which cannot compare to the small amount of RubyGems users, and > moreover of RubyGems fans thinking this system is perfect, and i don't > think such a reply Austin did would bring ppl to continue contributing > to Ruby at all. Ask me how much I actually care about that. I develop *RUBY* software. I don't develop Debian software. I don't develop Mandriva software. If I were to decide to make my software only as a .gem (not going to happen for various reasons), then it's not *my* problem to help you make things seamless for your users. I develop my software out of my own love for what I do and out of a sense of obligation. I *do not* have an obligation to solve *your* problems. I've never said that RubyGems is perfect. Ask the RG developers about some of the criticisms that I've had. But I'm going to be taking this thread and making some concrete suggestions that will solve likely issues -- and not keep on whining as I feel that I'm hearing from repackagers like yourself. > 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. *shrug* Look, the problem ultimately is that I'm not hearing anything concrete from the Debian folks, just a lot of FUD and "don't do this or we'll whine some more." If it seems like I'm sounding harsh, it's because I'm frankly tired of hearing abstract garbage about so-called perfect packaging systems from tired philosophies. RubyGems *is* here and it helps solve some very real problems. There are ways to improve it, but this pointless whinging doesn't help. Fortunately, there are people like Aredridel and Chris who can provide constructive feedback. And there's people like Hugh and myself who can take some of this vague nonsense and turn it into useful concepts that might able to be applicable to RubyGems that could simplify things significantly for other users. Which would you rather be? Someone who is actively helping the situation or someone who is FUDding? So far, the Debian contingent has been FUD. >> 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. Again, this is incorrect, as Gentoo's portage can also deal with precompiled packages. It's not common, mind you, but it can. -austin -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca