On 10/2/05, Devin Mullins <twifkak / comcast.net> wrote:
> Joshua Haberman wrote:
>
> > Say that you had two implementations of gems with identical feature
> > sets, but one used the "gem" command to do everything and one let you
> > use .gem files directly.  I would *much* prefer using the latter.
>
> Actually, it doesn't sound like they're mutually exclusive. Stick a
> little flag in the metadata.gz that says "I don't have a compile step!"
> and then it can be stuck on the $LOAD_PATH directly. Otherwise, upon
> require-ing something from inside the gem, you'll get an error "Install
> meeee!!"
>
> > Yes, I don't know the details of the current controversy (ie. why
> > Debian is having a problem packaging gems)
>
> Neither do I. Are they trying to repackage gems as... err.. whatever the
> apt-get file extension is? If so, why?

They're trying to repackage software that the author assume to be
Gem-distributed as Debian packages (.deb, IIRC).  The reason for this
is simple: To provide Ruby software on Debian for Debian users in the
way Debian users are used to.  These users do not particularly care
about Ruby, and definately do not want to have to know one packaging
system for handling Ruby software, and another for handling Perl, and
another for handling Java, and another for handling Haskell, and
another for handling Python, and another way for handling C code, and
...

Instead, they want they software to Just Work Like All Other Software,
the way they are used to, and to not have to care about the language
the software is written in at all.

The problem is when Gems provide guarantees to the authors that are in
violation of how Debian users are used to software working, and no way
to implement things the authors need in a way that is possible to use
with the way Debian users want.  Specifically, there's a problem with
the the-software-is-in-a-single-directory assumption.

Eivind.
--
Hazzle free packages for Ruby?
RPA is available from http://www.rubyarchive.org/