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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
