Re: RubyGems, upstream releases and idempotence of packaging

On 10/17/05, Mauricio Fern疣dez <[e-mail]> wrote:
> > > In my previous message, I tried to convey the idea that, given some
> > > conditions, a pure-Ruby .gem-only release is more akin to binary
> > > packages than to pristine sources.
> >
> > ".gem files should always be considered 'binary releases' in that
> > they're provided for runtime use, not for creating packages.  If
> > people want to create a package out of a project, they should seek out
> > a tarball or SCM access.  If a project releases .gem files only and
> > provides no SCM access, the (re)packager should bug the author about
> > this instead of complaining that .gem files aren't everything they
> > want."  Discuss.
>
> 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):

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. 
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
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
Z" involves such effort is misleading.  You don't repackage binary
distributions.

>     * 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!

> * 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"?

> I see the tradeoff as
>
>          (a)                                  (b)
>  RubyGems + Package  <======>    * repackaging effort
>  implementation cost             * upstream effort to ensure the
>                                    sw. works with and without RubyGems
>
>      (done once)                     (once per package)
>
>
> Moving towards (a) minimizes the global amount of work needed to
> develop, release, repackage and install Ruby software.

Sounds sensible, but I'm not enlightened on how this would be achieved.

> I'm willing to work on making that happen, and am thus helping Christian
> Neukirchen with Package. The approach we propose demands little to no
> effort from the RubyGems team.

Unless I'm particularly dense -- more than possible -- there seems to
be a lot of effort in understanding the proposal :)  I just re-read
your post at the top of this thread, and while I'm a little wiser,
there's still some way to go.  Have you spelled out the proposal
anywhere?  Not only the proposal, but an analysis of the proposal and
its implications?

Cheers,
Gavin