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

On Thu, 29 Sep 2005, Mauricio Fern疣dez wrote:

> 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

It wasn't my intention to be nitpicking, I was trying to address the
points he'd take the trouble to write, and I was trying to be
positive and not personal.

> 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...):

That's the spirit I was hoping for, thank you.
>
> *  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.

Yes, thank you for clarifying this.  Are there other things than
these 2 ....
> *  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.

...because now is the time to hammer them out, it seems to me?
>
> Can we move on now? We've seen random insulting, bashing of specific
> OSes and projects, outrage bursts and FUD accusations...

I'm sorry if what I posted came over as insulting, I was trying to
stick to the point and get concrete stuff we can work on, and may
have been too dogged.
>
> 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.

Most of this seemed (to me) to come from the Ruby rather than the
Repackager's side of things, which is why I was so determined to see
if we had covered all the issues that the repackagers have, hence
the "tell us, tell us, tell us!" tone.  I am unfamiliar with many of
the packaging systems, and have not used Debian, so assume there are
gaps in my knowledge about the necessary and sufficient conditiions
for harmonious coexistence.

I'm still puzzled about the use of the term upstream code.

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

I hope so. I wouldn't want the Ruby community's reputation tarnished
just because we hadn't tried to get the best system presently
possible.
>
> -- Mauricio Fernandez
>
>
         Thank you,
         Hugh