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

On Mon, 10 Oct 2005, Sean E. Russell wrote:

> On Wednesday 28 September 2005 08:54, Hugh Sasse wrote:
         [...]
>> fits your setup, then what is the problem?  Specifically: what can
>> gems do to make [re]packaging easier?

> A long time ago, before REXML was added to Ruby's CVS, I tried building a Gem
> for REXML, and the experience was an utter failure.  I admit that this
> colored my perception of RubyGems, because even back then people were pushing
> me to distribute REXML as a Gem.  I echoed Austin's attitude toward Debian

Probably one was me :-)
> packagers.
         [...]
>
>>> I only fear getting locked into using a specific library manager.  I (and
>>> you) expect the following process to occur:
> ...
>> Yes, but that doesn't actually mean to the exclusion of other forms.
>> There will be people making RPMs or whatever.  What can we do to
>> facilitate that?  Ruby culture has not been, in my experience, about
>> the one correct way to do things.
>
> I greatly appreciate that sentiment.  I suspect that addressing Mauricio and
> Elvind's issues would solve the problem.  Somebody else mentioned that being
> able to pass gem a command that would cause it to list its dependencies would
> be a big help.  I don't know; perhaps gem already has this.

I'd be in favour of that, having tried to get autoconf maintainers
to agree to do exatly that, unsuccessfully.
>
> I still have questions about gem's operation.  For example, if gem X depends
> on Y, and I've already installed Y but not as a gem, will RubyGems see that?

We may need the stabilisation of the naming conventions for that to
work correctly, because sometimes a gem with one name can unpack as
a library/executable with a slightly different name.  Else there
nees to be some way to detect Y, maybe by asking some ruby module.

> If not, then repackagers can't use the pseudo-solution that's been proposed
> of just wrapping the gem command.

Agreed.
>
> That would be ideal.
>
>> The firewalls issue needs to be addressed, definitely.
>> What's the nature of the problem?
>
> I don't know.  That it doesn't work?  Honestly, I've spent very little time

:-)  We will need a bit more than that to debug it. :-)

> investigating it.  As I've said, my interest in RubyGems has only gotten
> smaller with every interaction I've had with it.  By the time I got to the
> firewall problem, I had neither time nor interest in debugging it.  On top of
> that, I'm not sure I could justify spending time on it while I was at work,
> where I see the problem.

Except that doing so even to the extent where we get a stackdump
might make life much easier in the future.  If you can show us a
failure, others who have more time may be able to reproduce it and
help us squash it.
>
         [...]
>
> None of this will address the fact that I still firmly believe that the
> versioning system should be external to RubyGems.  I don't believe that it
> must, or should, be so tightly integrated.  For one thing, it means that core
> libraries will never be versioned, and there's no reason why they shouldn't
> be.  It is still much easier to fix bugs by upgrading a single library than
> upgrading an entire Ruby version -- for one thing, it allows core library
> developers to push fixes more often than Matz offers new releases of Ruby.

I'm beginning to believe it should be part of Ruby itself, i.e. that
require should behave roughly as the Gem version does now.
>
>>> "Carthago delenda est!"  --  The versioning mechanism must be separate
>>> from
>>
>> My latin's not up to that.
> ...
>> than disowning the problem, which won't just go away.   Why is such
>> support worse?
>
> "Carthage must be destroyed."  There was a Roman senator named Marcus Porcius
> Cato who would end every speech with "Ceterum censeo Carthaginem esse
> delendam", which means "And so, I conclude that Carthage must be destroyed."
> It didn't really matter what he was talking about... he said it endlessly,
> interjecting it into every conversation.

Thank you.
>
         [...]
> -- 
> --- SER
>
         Thank you,
         Hugh