On Thu, Oct 13, 2005 at 08:55:41PM +0900, Gavin Sinclair 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):
* 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
    * patching by the repackager (or the upstream developer) to ensure
      the software works without depending on RubyGems
* provide a mechanism to make it easy to give repackagers the input they need
  without affecting RubyGems' capabilities.

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.

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.

-- 
Mauricio Fernandez