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

On Wed, 28 Sep 2005, Ralph Amissah wrote:

> I'll greatly weaken my post, and give everyone the opportunity to head me
> off early by
         [caveats trimmed.
>
>> 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

Well, which is it, no solution or a solution?

> it if it promotes or
> complements the superior native solution i currently have; it is only

It complements it.   It is entirely orthogonal to it.

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

Rubygems holds no knowledge about .debs and thereby doesn't
interfere with their creation, destruction or anything.  If you
don't like the directory ruby (therefore gems) is in, then install
it somewhere else.

> 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

Its very easy for rubyists to use gems.  They are just different
from .debs.

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

This at present meets the needs of many rubyists.  We have been
trying to get debian people to be explicit about what would help
them build packages given gem unpack already exists.  I've not seen
anything constructive yet.  This is your best opportunity for input.

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

Yes.
>
> That said a language packaging system must play well with existing native
> packaging systems, it cannot replace them, (especially not for general

It isn't replacing them. It's entirely independent.  If you choose
to repackage every ruby script, gem, whatever, that is up to you.

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

We have explicitly asked what we could do that would help.  It has
been established that we need to do something about a DATADIR, which
may need changes to the core of ruby, for example.
>
>> 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.

There is, actually.  Matz has said he would like to get RubyGems into
1.8.4.  If we aren't to run into backwards compatibility hell, then
we need to get things as right as possible, now.  However, I note
there are no concrete suggestions in the above paragraph about how
we might achieve this.

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

Yes, we have gem unpack so you can get at the internals and
repackage them if you so choose.  What more do you want?  I have
asked that before: what more do you want?  If more options can be
provided to make that easier we are prepared to consider them.
>
> or at least
>
> (b)
> (i) Gems keeps out of the way of native packagers. and

Explain how it is in the way, given you can package ruby to go
wherever you like so that gems end up wherever you like.  Then
explain how this meets the requirements of the other N packaging
formats (RPMs, Sun, HP,...).  That last is on the basis that you
would not insist that the entire Ruby universe should revolve around
Debian packaging alone.  Tell us something concrete we can use.

> (ii) Gems does not in any way make it less likely that Ruby libs/apps get
> properly
> packaged, and

Gems are proper packages.  There is room for improvement, and we are
trying to work on that.  But we need concrete suggestions as to what
would help.

> (iii) Gems where used installs well without interfering in any way with
> native
> packaging systems. (and i assume this must have been worked out)

Yes, they go where ruby is installed.  And you installed it in the
correct place, right?  Yes, we know about the DATADIR issue, now.
>
> 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

You still haven't told us what you need that isn't there now, and
hasn't already been covered in this thread.

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

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

Very laudable, but you haven't said anything we can use.
>
> 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)
         [trimmed, makes no new points (being a summary!)]
>
> I don't think gems can seamlessly install Rails and its appendages (mysql
> etc.)

There seem to be a lot of people on the Rails list.  Seems to me like it
works.

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

Have you even attempted this?  I didn't need to install mysql again
since it was there already.  It just looks for the socket to connect
to.

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

And configure or install.rb picks up what is there....

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

But you haven't expressed anything concrete that we can use to shape
the future of Rubygems.
>
         [Further Debian advocacy and repeated points trimmed.]

It's great that Debian does what you wish.  The writers of Rubygems
have had to create something cross-platform that makes as few
assumptions about the operating environmemt as possible, and it has
been shown to work.   If there are further improvements needed, then
it would help to be as specific as possible, and it would help if it
benefitted as many packaging systems as possible.

i       Hugh