Fwd: RubyGems in Ruby HEAD
Right, let's get one thing straight here, because I have no interest
in a bunfight.
I'm not calling your OS names, because it's my OS too.
I'm asking what the alternative to manually translating gems into debs,
because that's a never-ending chore that causes problems.
On 23/09/05, Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote:
> On 23/09/05 at 10:47 +0100, Dick Davies wrote:
> > On 23/09/05, Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote:
> > > On 22/09/05 at 16:47 -0500, mathew wrote:
> >
> > > I think the solution to this whole flame war is to find ways to easily
> > > convert a gem to a {Debian,RPM} package, so packagers can package more
> > > apps more easily and provide packages for more ruby software than
> > > currently.
> >
> > The problems with that are
> >
> > * you are always going to lag behind
>
> Debian has stable, testing, unstable branches. Sometimes people want to
> lag behind for stability/security reasons. And if it's easy to package,
> the lag can be minimal.
I'ts a question of resources; if you're constantly reinventing the wheel
then there will always be a delay. I shouldn't need to run unstable just
because I want a new version of a library and apt-pinning is not for
the faint of heart.
> > * it takes no account of multiple versioning which is an essential
> > part of gems.
>
> Debian packages have been having that for ages ... Dependancies on a
> specific version, on > version, on < version, ...
I'm talking about multiple concurrent copies of a library coexisting
on a machine.
If I'm running a hosting server with each user running their own
custom rails app,
how do I support them all when I upgrade rails?
I don't think apt allows for that. And if it did, how would I express
what version
I wanted to use in ruby code?
> > * there's no way to have 'gem install rake' know that rake was
> > installed by a .deb autogenerated from a gem.
>
> That's why gems should be avoided except for developers really knowing
> what they do.
I can't see the chain of reasoning there at all. Are you saying the reverse is
true, and if I 'gem install rake' then 'apt-get install rails', I
won't end up with
two different copies of rake?
Unless I can be sure I'll never need to install a gem that Debian
doesn't provide,
I am going to have to deal with this issue.
> > Can't apt leverage rubygems instead of embracing and extending?
> > rubygems can't possibly know about every platform it could ever run on
> > - they've already done a lot of work to get it working on plenty of
> > different OSes - but the reverse does'nt have to involve a huge amount
> > of maintenance.
> >
> > What are the technical issues involved to having apt-get (or dpkg)
> > simply call off to rubygems?
> > It strikes me that if such a mechanism were possible, it could be
> > reused by the Debian project to support other external package
> > repositories,
> > which would save a *lot* of work for all Debian packagers.
> >
> > does anyone know of other operating systems that are able to delegate
> > package management in this way?
> > I know freebsd integrated rubygems into its ports tree recently, but
> > AFAIK that was an 'convert a .gem into a port' automated build, rather
> > than a "when I type 'apt-get install gem-foo, run 'gem install foo' "
> > delegation technique.
>
> What makes gem & ruby so special that they should have their own package
> system ?
They aren't special. That's my point. This is a general problem with
all language-specific package repositories that are used by a
system-specific
packager.
This issue isn't just about Rubygems, or Debian.
> I think having "apt-get install" call "gem install" is never
> going to happen. With lots and lots of work, you could maybe convince
> the debian-ruby people, but you will never be able to convince all
> debian developers.
That's a back of a fag packet plan. I'm not talking about it as an
implementation,
but you guys have probably been using Debain for more than three weeks, so
I'd hope someone might have come across this issue before.
Why can't a package run a command rather than untar some files?
> I don't think gem does everything APT can do. For example, if your gem
> include a shared library written in C, does "gem install" compiles it ?
Yes.
> I think the efforts should be targeted at making it more easy to convert
> gems to distribution packages, and making it more easy to follow
> releases of new gems. This wouldn't be Debian-specific but would help
> all Linux distributions.
And so it would have to be flexible enough to support all package
tools for all existing and future operating system versions - not just
Linux, not just Unix.
That's a much bigger job than what I suggested Debian did (which would
be a one shot thing), and is not going to happen.
Especially when you consider the alternative works fine
1 install the half dozen packages Debian splits ruby into
2 install rubygems (won't be necessary before long)
3 add a compiler
4 gem install whatever
--
Rasputin :: Jack of All Trades - Master of Nuns
Reply to: