Re: RubyGems, upstream releases and idempotence of packaging

On Thu, 13 Oct 2005, Mauricio Fern疣dez wrote:

        [lots of good stuff trimmed]
> This is what I think we can do to prevent such problems:
> (1) make sure that the source code contained in the .gem is the same we'd have
>     in a separate, non-RubyGems-dependent tarball, meaning that it can be
>     installed and used without relying on RubyGems; in practical terms, that it
>     will run when unpacked in sitelibdir, that there are no DATADIR problems,
>     etc.
> (2) either
>     (a) make sure that .gem files can always be rebuilt with the data used in
>         the .gem itself
>     or
>     (b) ensure that the data used to generate the .gem originally is available
> 

Good strong, clear arguments there. 
I'm in favour of this for your stated reasons, but I have a
question:  Does this mean that binary gems would be impossible?  
Or at least forbidden?  Some packages are distributed for windows
only, which saves on download size, disk space....

(I'm not sure about "idempotence" being the right word as you can't
turn something into a gem n times, without unpacking it in between,
and have it the same as doing it once, but that's a terminology
debate of little value.)
> 
> [1] One can extract the data with 
>    
>  tar Oxf foo-0.0.1.gem data.tar.gz | (mkdir foo-0.0.1 && tar -C foo-0.0.1 -zxf -)
> 
I'm not sure I understand that: you are extracting data.tar.gz from the gem
(which is basically a tar file), and the name 'data.tar.gz' will be
written as input for the next command, which creates it in the
foo-0.0.1 directory just made?

> The "nested tarball" format was inspired by Debian's .deb format. The latter

Can you point me at something which explains the point of nesting?
I've not clicked.  
> 
> -- 
> Mauricio Fernandez
> 
> 
        Thank you,
        Hugh