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

I'll greatly weaken my post, and give everyone the opportunity to head me
off early by
admitting, i should not be engaging in this discussion, I know too little on
the
subject, (i have not yet used gems, i have some idea of their capabilities)
and
have followed only a few related threads and then only with peripheral
vision. That said
i am "interested" and alarmed enough to make noise now, lest i am made to
regret not
having done so later, as appears increasingly to be a possibility.

Actually (not having followed the discussion in any detail) I speak mostly
to give
others who are concerned, and more engaged and knowledgeable than myself
on the subject, the assurance that they do not speak alone. And in the hope
that
all kinks that remain as issues for native packagers of ruby libraries and
applications
(aka repackagers) are ironed out.

Once native packagers are no longer concerned, well, i suspect my concerns
will have
been met, and i will not be concerned either. If that has happened already,
well good,
things have developed positively, I am late, and we can move on.

I wait to hear their reassurance.

(it will also be clear that i have had a positive experience with Linux and
Debian and
have a rather different estimation of the value and importance of native
packaging
done right. Debian and Ruby, i am very pleased to have spotted both of
those).

Austin thanks for such an extensive reply we have fundamental differences of
opinion
on several things though. At the end of the day, i will be glad to be wrong,
and for things
to go on smoothly should Gems be introduced, without the slightest hiccup
for me using
my choice of computer system, with the introduction of Gems.
Indeed no hiccup is what i seek... and which is why i am slow to like this
idea.

>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.

You have no solution, I have no problem (or seldom do). The solution
suggested is not equal to,
and cannot be, to what i currently have. I only have real reason to welcome
it if it promotes or
complements the superior native solution i currently have; it is only
acceptable if it does not
interfere with what i have got: not in the way it installs; not in the (eas
of) preparation by others of
packages for my system; not technically (or otherwise) in the likelihood of
packages being made
for my system...
Surprise i am a Debian user, i am one of those who currently has things good
with his system
and tends to complain and fear the possibility of negative change,
(especially change
promoted by one (or people) who has actually looked at and somehow failed to
see this
goodness in the system of which i speak).

>> 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 do care... this is one of the reason i looked round and settled for using
Debian.
They do care about packaging.

The philosophy of taking packaging and packaging systems seriously and
making
sure that they work well (both by technological means and by means of
policy) may be
one of the reasons it appears to be so easy for the Debian system to be so
much
better than so much else, when it comes to packaging (amongst other things).
They _do_ *care*... always have, even when stumbling with issues along the
way,
the eye is on the longer term solution, and diverse needs of various
developers and
users, and in multiple hardware environments... oh and did i say, they don't
rush into
things either, by rush, and the definition of rush traditionally has not
been time based,
but getting things right.

Others must care as well, there are other decent native packaging systems
out there.

That said a language packaging system must play well with existing native
packaging systems, it cannot replace them, (especially not for general
users). It plays well
at the very least if not able to help, by making sure it does not hinder,
making sure it gets
and stays out of their way. (Given that it is being designed from the ground
up for Ruby,
it should take into account these interests and be designed also to help).

>I *am* offering proposals that, if provided, should help.

ok, glad to hear it, i am sure they go some way towards meeting them.
If the native packagers say your proposals achieve what needs
to be done, fine.

My only concern is this. Get it (Gems whatever) right before anything goes
in.
Given the fact that these concerns were expressed at the outset, and still
have
not been fully met... well, fix them first, then consider. There is no rush.
Not getting this right would be a flaw that depreciates the value of Ruby.
There is
no hurry.

OK if:

(a) Gems helps native packagers (ok i am told this is not its' purpose)

or at least

(b)
(i) Gems keeps out of the way of native packagers. and
(ii) Gems does not in any way make it less likely that Ruby libs/apps get
properly
packaged, and
(iii) Gems where used installs well without interfering in any way with
native
packaging systems. (and i assume this must have been worked out)

that is good to know, i could use them (as in install things with them) say
when
developing or in an emergency. But without (a) as regards making packages i
am
still looking for a ruby packaging system, that takes the first step towards
doing
what i need, and hoped for in a basic Ruby packaging system, certainly one
that
sought to be integrated so closely into Ruby.

Unless gems does (a) I continue to await its arrival and will value its
arrival
more than Gems.

This said i am a bystander, who wishes to ensure that this impinges as
little
as possible on the beauty of the ecosystem in which Ruby and software
generally
works for me, it happens to be Debian, but could possibly have been
something
else.

I am perfectly happy that gems should be able to live beside it; but it
should
not interfere, and in no way should it make packaging for it more difficult.

summary without (a) it seems Ruby is still looking for a Ruby solution(s)
that
makes it as easy as possible for native OS packagers. It seems further that
such a system does not compete with Gems. I am likey to find more value in
such tools than in Gems, and am yet to figure out how much benefit there
would be from being one standard such system, (i tend towards choice).

I don't think gems can seamlessly install Rails and its appendages (mysql
etc.)
if it can, i don't think gems can seamlessly install them on my system
whatever
that may be in such a way as it (rails mysql whatever i need to make it run)
is
part of my system, if mysql is already there know and not install that that;
if
libraries are already on my system, i don't want to install them more than
once.
I don't think gems can seamlessly install SiSU for me, and integrate
its parts on my system.

This is presumably not what Gems is or should be trying to do.
This is largely the realm of native packaging systems,
this is why i use them, and why where they work, and Debian for example
does,
we love them.
And this Gems (or whatever alternative might be proposed for *core*) should
ideally promote if it is capable, and if it is not, must in no way hinder.

>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.

Sour grapes sounds a disingenuous characterization of genuine existing
concerns.

rpa sought to communicate these needs, and to work with Gems, despite
reservations, and went out of their way not to compete with Gems, and
even contributed substantial amounts of code to Gems.

from what i am reading at this time, it seems rpa should instead have
produced a Gems replacement (not rpa that was something different,
and it would appear a considerably more difficult task).

I don't speak for rpa, i do frequent the irc channel because there has been
a lot to be learnt about packaging from people there; and i have been help
on occasion by good folk there.

[Mostly OT and on Debian]

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

Re arrogance, I would say we have much in common with Debian

>
>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 colossal failure of open source.
>

Don't feel sorry for me on this Austin.

Debian is a resounding success, with reason and very little promotion. All
else
apart, the choice offered, well near staggering.

As for the individuals involved well, there are no doubt issues. Characters,
some arroganct no doubt, strong views, much like you and i. I think at one
time
the debian irc channel may have got itself a reputation for being hard,
perhaps
it still is? But they are individuals, a motley bunch, (and perhaps there is
a
bit of an insider culture or insider cultures there are so many of them),
and
perhaps sometimes the more aggressive are the ones who get heard.

>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.
Debian is wonderful technically.

If your problem is with Debian philosophy, note only that is similar in a
number of ways to that from which Ruby is derived, i am thinking mostly of
licenses here. Perhaps you are talking about arrogance again here, i wonder.


did i say, i have a new computer from a software perspective every day,
(updated system)? and 15,000 packages to choose from? and that the packaging
system works?... oh, and it only installs each of those 15,000 things once?
except where special circumstances have to be catered for, which it knows
about on its own? as a user i am not concerned about what language software
i
use is written in, only it's utility, oh and i don't need to spend much time
on
it, (setting up) Debian, i can get on with whatever it is i do on my
computer?
Love it, and like Ruby, with good reason.

On a related note it is hardly surprising that Debian packagers show
interest
in what Ruby proposes to come up with for packaging system, they are more
interested and know more about packaging/packaging systems and packaging
policy, than most, and have always looked towards the long term scalability
and
stability of their systems, even when things have not worked perfectly they
have looked towards such ends. We should listen more to them. It is fairly
easy
to see why it works so much better, than other packaged stuff out there.

Incidentally there is a recent decent technical book on Debian:
The Debian System: Concepts and Techniques by Martin F. Krafft
I have it in a really nice hardback edition, published in Germany,
http://www.opensourcepress.de/index.php?26&backPID=15&tt_products=16
for most of the rest of you it is published in not quite as attractive bound
form by No Starch Press:
http://www.amazon.com/exec/obidos/tg/detail/-/1593270690/

Back to Ruby Core

>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.
>

This one surprises me though, i would have thought that Matz would seek to
ensure that a ruby packaging system that worked well with other packaging
systems... (and thought he might even have said as much quite early in Gems
development?). I thought Gems would have been engineered with such a view in
mind, whatever else they do, what could Gems, or i be thinking? Why are we
still talking about it now.

On introducing a system like this inside Ruby the onus should be strongly on
those seeking to introduce it to satisfy others with an interest in Ruby
that
it meets their general requirements.

>> 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.
>

I don't see how anything about ruby packaging can be considered *solved* if
it
is proposed for ruby core and has failed to take into account this aspect
that
has been presented as a concern from close to its inception.

It's not late, there are things to be done, with or without Gems.
Right now get Gems right, then ask to have Gems put in core.
If Gems have been put right, fine.
If Gems can't be put right, don't.

Ralph