Re: RubyGems, upstream releases and idempotence of packaging

On Mon, 17 Oct 2005, Gavin Sinclair wrote:

> On 10/17/05, Mauricio Fern疣dez <[e-mail]> wrote:
> > We're considering the following alternatives (the initial assumption is
> > that we want repackaging to happen so that end users can install Ruby
> > software the way they choose --- or they're allowed to):
             ===================  This is the important aspect:
> 
> Yes, valid assumption, but my point is about "repackaging" gems vs
> "packaging" pristine sources.  The goal ("end users can install...")
> isn't necessarily hampered by gems being repackager-unfriendly. 

It is in the case where the user wants to install the gem as it
would be installed by their packager, so that they use "one tool to
manage them all, one tool to find them".

> That's the point I want to see argued.
> 
> If the answer is "that's true, but there's so much to be gained from
> making gems repackager-friendly", that's fine.  But I want to be clear

This is the thrust of the argument.  It makes repackagers happier,
it makes people who will only install things as packages happier,
and it reduces noise on the list.
> that that's the answer.
> 
> > * accept the status quo: do to the "binary" nature of RubyGems packages,
> >   often attempts to repackage them involve:
> >     * requests to the upstream developer for the pristine sources
> 
> That's not repackaging a gem, that's packaging some pristine sources. 
> The gem is incendenary and not involved.  Saying that "repackaging gem

"incendenary"?  Nearest match I can come up with for that is
"incendiary"  :-)  Liable to create flame wars :-) ?

> Z" involves such effort is misleading.  You don't repackage binary
> distributions.

I think, from the context of the discussions so far, this is about
not having all the files and information necessary to create an RPM
or other package because the information about what can be moved
around to data directories or whatever is missing in the gem.  So
you ask the author for the information, original directory structure
or something.

> 
> >     * patching by the repackager (or the upstream developer) to ensure
> >       the software works without depending on RubyGems
> 
> It's perfectly reasonable for a gem distribution of software to depend
> on RubyGems, and it's unreasonable to complain about the effort in
> removing that dependency.  My point in the "discuss" paragraph is that
> it's up to the author to decide what dependencies they want in the
> code.  A Debian repackager is welcome to make a package of the same or
> different code, but they are not welcome to complain that a .gem file
> contains a dependency on RubyGems!

Except that they argue it makes life more difficult, because
rubygems doesn't handle packaging issues as they need it to, so they
don't want to have it, then having software depend on it locks them
out.  The line of thinking is "gems are meant to make things
easier for people, but for those who use one packaging system for
their machine it makes things more difficult, and can something be
done about it, please?"  
> 
> > * provide a mechanism to make it easy to give repackagers the input they need
> >   without affecting RubyGems' capabilities.
> 
> So that's the second alternative?  I don't understand what it means. 
> What's "the input they need"?

The files they would need to create a package, having squeezed the
gem to get them out (using unpack or some other method).  My point
about binary gems was due to the desire to still have them for
platforms/situations where it makes sense.  Clearly one cannot
repackage from a binary gem.
> 

        HTH, and hope that I haven'd distorted anything,
        Hugh