Re: RubyGems in Ruby HEAD
Marc Dequènes (Duck) wrote:
mathew <meta@pobox.com> 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
Reply to: