On 10/3/05, Austin Ziegler <halostatue / gmail.com> wrote:
> Joshua wrote:
> > The package install/uninstall are only easy if your system setup
> > matches the assumptions implicit in the design of the "gem" command.
>
> This is a completely incorrect statement. I'll leave it to the reader to
> actually *think* the concept through.

Since I'm unable to understand what you mean here, I'd appreciate it
being spelled out.  My understanding matches Joshua's at this point,
and I'm wondering whether it's you or us that's missing something.

> >>> There are many cases where "gem install" is not suitable, but "tar
> >>> xf" is.
> >> I'd love to know one, for a .gem. Seriously.
> > - you want to install Ruby and a bunch of gems onto a software
> >   partition that will be mounted read-only from tens or hundreds of
> >   nodes.
>
> This has nothing to do with RubyGems,

It has to do with the layout policies of the platform it is being
installed on, and how directories are supposed to be picked by
software.  That's normally managed by the package manager & packagers.
 When RubyGems is taking that role, it suddenly ends up having to do
with RubyGems.

> > The philosophy inherent in "gem install" -- that I am going to
> > "install" the gem on any machine that will ever run it, and I will
> > have write access to do so -- is narrow and brittle.
>
> Then restrict the availability of the gem command. It's not *that* hard,
> and suggesting otherwise is a cop out from someone who doesn't get it.

You misunderstood the comment here, I think.

> > I'm not opposed to the existence of "gem install/uninstall."  I am
> > opposed to any attempt to force people to use gem install/uninstall
> > if it is not appropriate for their situation.
>
> It's never *not* appropriate.

That's religious.  There are, as far as I know, still cases where
RubyGems do not work correctly with the local packaging systems
(unless somebody has been doing magic overnight :)  For those that see
those local policies as more important than whatever RubyGems offers,
"gem install" is inappropriate.  I can list cases easily, and so can
you.

> Or you do a local install. Don't throw up roadblocks because you don't
> understand what is actually offered -- and don't pretend that Debian or
> FreeBSD's solution is "All That."


> If it isn't a good Ruby solution, it's not a good solution.

True.

> Pandering to a single platform is most certainly not a good solution. Pandering to
> two platforms is equally a bad solution. Pandering to +n+ solutions is
> even worse.

Pandering to a single language - by breaking policies - is a bad
solution for any platform.  Pandering to +n+ languages is even worse.

> Writing a good solution -- and this *is* RubyGems -- that
> offers hooks for packagers to use *while using the existing
> infrastructure* is a much better option for Ruby and for everyone else.

The question is "Do RubyGems offer hooks that work correctly for repackagers?"

At present, with my repackager hat on, I'll say the answer is a "no".

The important question is "How can we make the answer to that question
a 'Yes', and keep present good aspects?"

Eivind.