Re: gems is a language change, not a pkging system

Hello,

[I'm not going to reply individually to nearly every sentence you wrote,
as you did with Ralph, because that quickly degenerates into nitpicking
and quarreling, but I'll include (most of) what you wrote to give some
context to a few comments.]

On Wed, Sep 28, 2005 at 08:32:48PM +0900, Hugh Sasse wrote:
> Rubygems holds no knowledge about .debs and thereby doesn't
> interfere with their creation, destruction or anything.  If you
> don't like the directory ruby (therefore gems) is in, then install
> it somewhere else.
[...]
> We have explicitly asked what we could do that would help.  It has
> been established that we need to do something about a DATADIR, which
> may need changes to the core of ruby, for example.
[...]
> Yes, we have gem unpack so you can get at the internals and
> repackage them if you so choose.  What more do you want?  I have
> asked that before: what more do you want?  If more options can be
> provided to make that easier we are prepared to consider them.
[...]
> Explain how it is in the way, given you can package ruby to go
> wherever you like so that gems end up wherever you like.  Then
> explain how this meets the requirements of the other N packaging
> formats (RPMs, Sun, HP,...).  That last is on the basis that you
> would not insist that the entire Ruby universe should revolve around
> Debian packaging alone.  Tell us something concrete we can use.
[...]
> Yes, they go where ruby is installed.  And you installed it in the
> correct place, right?  Yes, we know about the DATADIR issue, now.

Some of the following points are obvious (or they might only seem so to
me because I've been involved with RubyGems & repackaging issues for so
long...), but it seems it is necessary to restate them to center the
discussion (please read as a whole and see where I'm trying to go...):

*  While the .gem package format now allows for easy extraction of its
   contents, the contents themselves might depend on RubyGems, and the way
   RubyGems installs them, to execute correctly. It's all about the contents. 
*  Such dependencies are caused by things such as lack of DATADIR support and
   require_gem. This is why many knowledgeable people consider that RubyGems
   packages are hard to repackage.
*  These issues affect all the systems that don't manage Ruby packages
   the way RubyGems does it (most predate it). I'm being told so
   by Debian, PLD and Suse developers (I haven't been able to get in touch
   with other repackagers yet). I was also told so by a FreeBSD
   developer, but at least one FreeBSD developer disagrees with him or
   thinks that wrapping gem install is an acceptable compromise for the
   system.
*  This has been known for a long time and it seems these issues are
   now going to be addressed.
*  It is possible to change RubyGems so that RubyGems packages are not 
   repackager-hostile without compromising the features that have made it so
   popular (like versioning).
*  Which changes and how to do them is what we should be talking about.
 
Can we move on now? We've seen random insulting, bashing of specific
OSes and projects, outrage bursts and FUD accusations...

Could we focus on what needs to be done, and how it's going to
happen?

_why proposed a list [ruby-core:5877] and further refined it in
[ruby-core:5950]; the latter incorporated items added by Chad Fowler
[ruby-core:5880] and Jim Weirich, who also prioritized them in
[ruby-core:5901], without specifying the sorting criteria, though.
Austin Ziegler created the so far most detailed list [ruby-core:5882].
I tried to assign priorities to the latter based on the impact on
upstream code in [ruby-core:5890]. Unfortunately, the latter was largely
disregarded, but I'd appreciate constructive criticism.

Let's see if anything productive can come out of these threads.

-- 
Mauricio Fernandez