Re: gems is a language change, not a pkging system

On 9/27/05, Ralph Amissah <[e-mail]> wrote:
>> Right now, they're watching people who have pretty much sat on the
>> side of the whole process, if they've even been involved at all,
>> savaging their work -- their labour of love -- because it doesn't
>> meet their idea of intellectual or packaging purity. *NOT* because it
>> causes real problems, but because it makes things harder for
>> repackagers.
> Labours of love are no excuse for forcing an idea that does not work
> for others upon them.

Sorry, but the idea -- that is, RubyGems -- works. The problem -- a Ruby
packaging system -- exists. Do you see a solution other than RubyGems
being available? I sure as hell don't, and that's the problem, Ralph.

Matz committed in late 2004 to early 2005 to putting a packaging system
in the core. He very clearly stated that this was not necessarily
RubyGems. In this time, no one has seen fit to create an alternative to
RubyGems. Now that it's time to integrate a *successful* packaging
system into the core, we've got the peanut gallery crawling out of the
woodwork saying "it's a bad idea!" Do they offer an alternative? No.

It has been a goal of RubyGems to be put into the core libraries from
the beginning. This has been known (trumpeted and shouted, even) since
RubyGems was started. Has anyone seen fit to develop a viable
alternative to RubyGems? The rpa-base effort floundered. So, where's the
alternative, Ralph?

Coming out at this late date -- and without an alternative -- is just
sour grapes.

> There is a question as to whether this belongs in the standard library
> as it does not.

Actually, there is no question as to whether it belongs. Matz has said
that it belongs, and I agree with him. Indeed, I think that if there
were a viable alternative to RubyGems (and, of course, there isn't!),
Matz might ask whether RubyGems itself belongs. The question is how we
get RubyGems into the core.

> And the Labour of Love will be appreciated and used by, well those who
> appreciate and use it. (As well you appreciate in your expressed
> frustration, and apparent dislike of Debian). That said I much
> appreciate the contributions of various people including members of
> the Gems team to Ruby.

What I dislike about Debian is the arrogance of the philosophy.

> How many balls of string do you need to reach the moon, ... indeed it
> is a big one:
> * Gems must not make it MORE difficult for repackagers. What on earth
>   would be the point of that. Ruby programs/libraries should not be a
>   second class software on ANY OS. Nothing should be done that in any
>   way makes this more likely. (How many programming languages are
>   there, if they all had idesyncracies which created difficulties (for
>   those who offer seamless larger systems) what kind of a mess would
>   there be, and why should Ruby choose to turn itself into a language
>   that is regarded in this light.)

Sorry, but I disagree -- and that you can even ask this question
suggests that you haven't read my proposals. I talked these over with a
few folks on freenode#rpa the other day and got guarded agreement that
the proposals would certainly make things *far* easier for repackaging
without sacrificing what RubyGems offers. Frankly, I *have* worked out
what it would take, and while there are minor flaws in my proposal (as
pointed out in that discussion, most packaging systems have bizarro ways
of tracking the database of installed files), it's a good proposal.

> Work that out, then offer us Gems "in ruby head"
> Whatever you come up with must play WELL with existing packaging
> systems.

I frankly don't care if it plays well. I never have, I never will. I
*am* offering proposals that, if provided, should help. But the silence
from the repackagers is astounding, and one repackagers said as much
that even if the things suggested were provided they wouldn't be used.
What motivation is there for working with the repackagers at that point?

> As I understand it Mauricio has made his issues with Gems known at all
> stages of development, and continues to do so; and he has in the past
> contributed a fairly high percentage of code to it. Some of us have
> been content until now to sit by and watch him labour in our
> interests.

Actually, no offence, but Mauricio's code represents a fairly low
percentage of the total. It represents the packaging format, and that's
it. Most of that is reflected in Archive::Tar::Minitar. It's good code,
but Mauricio continues to believe that installation in site_ruby is the
Right Way. I disagree with him on this for a lot of reasons.

> I do use Debian, I even now package with/for Debian. I find myself
> drawn increasingly to it, perhaps because my experience with Debian
> has been very different from the one you continually describe, perhaps
> i took the time to understand the tool a bit better, 15,000 packages
> available to choose from + and very few issues, updated/upgraded
> daily. It's a bloody astounding achievement, AND it is not some little
> package management system, it is used by almost as many Linux
> distributions as Red Hat, AND it could in future work just as well
> with say FreeBSD, ... though i for one am very happy with Linux.

I'm sorry for you, then, because the Debian philosophy is one of
arrogance, not service. I dislike working with Debian developers, in the
main, as much as I dislike working with Gnome developers. Debian, IMO,
represents a collosal failure of open source.

> Having said this, i do not think the problem is in any way confined to
> Debian repackagers, or Linux alone at that.

It's mostly confined to Debian repackagers and Linux. The other
repackagers with which I have discussed the proposals I've made haven't
seen any particular problem with them and have indeed suggested that
they could make repackaging a .gem dead simple.

> A last point on repackaging, If i am an inexperienced user of an OS, I
> probably do not want your Joe Random, software installed directly on
> my system unless I have had a group i trust review it (whether a
> company or other), approve it, and assure me it will play well with my
> system.

This is irrespective of packaging or repackaging. It also conflicts with
reality. (Otherwise, Windows users wouldn't continually be infected with
adware, spyware, trojans and virii.)

> It is unlikely i will engage further in this debate, but i am sick of
> seeing this shoved as some wonderful solution, and a done deal, if it
> fails as obviously as you and others state it does, in what should be
> one of its more obvious and primary objectives (in addition to
> whatever else it might do for you).

Sorry, but it has never been an obvious or primary objective that
RubyGems should help people who want to integrate with native packaging
systems in ways that are in and of themselves not compatible with
RubyGems philosophy. The RubyGems developers that I have spoken with
have suggested that solving the Ruby packaging problem has been the most
important thing, and everything else is secondary.

> Let us see something we like and can agree with first, certainly don't
> let us obligate ourselves to having worse, unless perhaps, an
> alternative that works for the rest of us can be introduced into the
> Standard Library/Core whatever once that has been prepared. Indeed as
> it probably would be, if those politely 'sitting on the side' and
> trying to persuade developers of their needs, had gone ahead and
> produced an alternative system that worked better and could be
> proposed instead.

The anti-Gems folks have had a year or more. Where's the alternative? If
there is none, then Gem is the right answer. Now help us *get* it there
in a way that will help you without violating the core philosophy and
functionality of Gems (which, at this point, does include versioning)
and commit to *using* that, and you're not being obstructionist.

> This thread goes on because people are not sitting idly by.

Except, Ralph, they have been. The alternatives to RubyGems don't exist.
Code speaks a *lot* louder than Debian repackager whinging.

> (and hands off Debian it is WAY WAY Better than Windows :-)

Actually, it isn't. Its packaging system is cleaner, perhaps, but Debian
sucks. I personally *would not* choose a pure Debian system for
installation on any of my systems. A Debian-based system that
pragmatically solves the philosophical nonsense behind Debian, perhaps.
But not Debian itself.

-austin
--
Austin Ziegler * [e-mail]
               * Alternate: [e-mail]