Hello again,
Lucas Nussbaum wrote:
> - rubygems. ruby 1.9.1 will include rubygems in stdlib (it hasn't been
> imported yet, according to [EMAIL PROTECTED]). This means that we
> will have to decide whether we continue to package libs from .tgz, or
> if we want to package some rubygems too.
What do you mean by 'packaging rubygems' ? Would it be reasonable to
put the .gem file in a debian package, and have it installed by rubygems
at configure time ?? I argue against:
* we'll have great pain whenever rubygems has a simple bug, because
we'll need to deal with that in post-inst and pre-rm; I foresee
nightmares about this
* we're wasting disk resources by having both the .gem and the
unpacked gem
* we'll have trouble with gems with binary code.
> I had a long discussion with Eric Hodel (brbrain), and I think that we
> should package gems. But there's a number of issues that should be dealt
> with first:
> - when run 'normally', gem should not install to /usr/lib/ruby/gems, but
> to some place under /usr/local, to avoid clashes between debian
> packages and manually installed gems.
> - binaries from rubygem packages should be installed to /usr/bin, while
> binaries from manually installed gems should go to /usr/local.
> - rdoc documentation should be installed to /usr/share/doc
I agree with all these considerations.
> - what about ri documentation ?
I don't know how ri lookup works, but it really should return all
documentation installed on the system. Currently, ri files go to
/usr/share/ri/$version/ , so we might want to install ri documentation
into /usr/share/ri/dist/$version ?
Cheers,
Vincent
--
Vincent Fourmond, Debian Developer
http://vince-debian.blogspot.com/
-- pretty boring signature, isn't it ?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
