Re: RubyGems in Ruby HEAD
Hi!
I'm another, less involved, Debian ruby lib maintainer. Of all the things
that have been tossed around in this thread so far, I see these two as
being the really interesting ones:
On Wed, Sep 21, 2005 at 03:56:00PM +0200, Paul van Tilburg wrote:
> Ok. Some concrete stuff then.
> * Upstream should only have to create a spec file, not change stuff in
> the code, let 'require "foo"' stay 'require "foo"'.
This is the big one for me. The packaging stuff is metadata and should
remain separate from the code. Granted, as a packager I could simply route
around this by patching every single ruby lib I package, but it's still an
ugly implementation that makes life annoying.
I haven't looked in to the actual gems implementation in a few months, so
the details are sketchy in my memory, but is there a way of keeping the
code and packaging metadata separate that wouldn't break the existing gems
implementation?
Better yet, does anyone remember a thread where this sort of thing has been
discussed in concrete terms?
> * Create a mapping from gems to libs. This way, we _can_ include
> RubyGems into Debian without problems. The user can get libs that
> haven't been packaged yet or newer versions but is warned when gems
> are installed overriding a lib that already has been installed via
> dpkg and vice versa.
> This probably sound much more easy than it is, and it's also
> more of a workaround.
I don't necessarily expect the gems guys to handle this, but if it were
handled by the gems packagers themselves it would potentially solve a lot
of issues. Austin obviously speaks for those developers who want complete
control over their code, and giving them the ability to do this would
definitely make repackagers' lives a lot easier.
Would a simple field in the gemspec that we could parse automatically
handle this well enough? If not, what else do we need?
- David Nusinow
Reply to: