[csw-pkgsubmissions] newpkgs ruby19, ruby19dev, ruby19ri, ruby19sa(...)

[Ben Walton]

Excerpts from Philip Brown's message of Fri Apr 09 15:06:25 -0400 2010:

> This sounds... quite bad.

Go tell the ruby folks then. :)  It's really no worse than a breakage
caused by perl 5.8 -> 5.10 or python 2.x -> py3k.  Languages change.
Bindings and modules always lag.

> > It doesn't work like that, unfortunately.  If you're running 1.8 with
> > a Rails stack (installed locally as gems, outside of the pkg world)
> > and all of a sudden we drop 1.9 in the place of 1.8, you're going to
> > annoy a lot[2] of people.
> 
> Technically, that's Not Our Problem, until we package something in
> that category.

So we'll bend over backwards not to break NFS or sparse zones where
it's _hard_ to meet all the needs and yet say 'fffffuuuuuuuu' (see:
reddit) to those that simply installed some gems using a supported
package when it's easy not to screw them?

> We might approach this, by migrating CSWruby to 1.9, but then
> providing 1.8 as "ruby_old" or something?

That only makes sense when 1.9 is ready to be the default.  I don't
believe that's the case yet.

> (I really dont like having "18" when it's really "1.8". Yes I know
> we do that for bdb. I hate that :-/ )

If package naming will allow for 1.9 (and 1.8), I'll change both the
name and the binary filenames.  This would be closer to what Debian
does, but I opted for shorter names without dots.

> > People want both.  Some will _need_ both, at least for a while.
> 
> I dont think mangling our namespace quasi-permenantly, for a
> temporary benefit, is a positive thing.

> Would you care to test out our existing ruby-using packages, and
> verify whether or not they will work with 1.9 ?

No, not really.  I don't have personal need for this yet.  I packaged
it due to _user request_ and while I'll certainly play with it for
scripting purposes, I won't be deploying it to run anything like
puppet or rails on my own boxes in the foreseeable future.

> Otherwise... if they DO all work.. seems like "upgrade ruby, provide
> ruby_old" might be our best course of action?

Lets look to the other distros for this:

Debian provides a package named 'ruby' which is a dummy package that
depends on default debian ruby version, ruby1.8 currently.  They ship
an additional 1.9 package.

Fedora 12 doesn't provide a 1.9 package that I could see.

So, if you're proposing the following, I can agree to more work.
Otherwise, I think my original plan is still the best option at this
point, with the minor exception that I'm willing to make our 19 be
1.9, assuming we'd demote the current ruby package to 1.8 later.

1. Rename current ruby packages to include 18 in the name (ruby18,
   ruby18doc, etc).
2. Make binary/path names use the 18 suffix (or maybe 1.8,
   depending...)
3. Add dummy packages in the place of the old ruby packages that
   simply depend on the current _default_ version (must be 1.8 for
   now) that provide symlinks in all required areas to make the 1.8
   version work.
4a. Ship the ruby19* packages, as is, since they'll still play nicely.
4b. Ship the ruby19* packages with binaries/paths using 1.9 instead of
    19 as they stand now.

1 and 2 above are tangled up in the fact that I can't currently
rebuild 1.8.7 as gcc4 is broken...the breakage isn't affecting 1.9
currently.

3 above is tangled up in that there will be several paths that need
symlink behaviour.  It's also complicated by the fact that binary
modules may have RPATH built in.  (Had we had this version naming
stuff built in from the start, things would be easier, but ruby was
around long before I took it over...and even when I took it over, 1.9
wasn't as popular as it is now.)

I think the best course of action is to follow Debian in this.  When
they flip their default version, I'll do the same for OpenCSW.

Thanks
-Ben
-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302