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

Ben Walton bwalton at opencsw.org
Tue Apr 20 04:56:54 CEST 2010

Excerpts from Philip Brown's message of Mon Apr 19 15:25:24 -0400 2010:

> - we maintain version-specific packages of ruby
> - we maintain them only so long as WE need them for OUR packages
> - once none of OUR packages uses an older version, we drop it
> - there is no generic "ruby" package, since it is guaranteed to
>   cause problems in the future due to shortsightedness of the ruby
>   developers.

Ok.  This is livable.  I'm certainly in favour of less work (eg: fewer
packages) going forward.  I think the only point I'd make about the
above list is that older versions should only be dropped as of a new
stable release.  This will hopefully ease things for people with gems
installed locally (I don't want to get into gem packaging...)  that
have the potential to break across version upgrades.  We shouldn't
just drop one of the ruby versions at 'random.'

> So... we COULD replace all our "CSWruby*" packages, with "empty"
> packages that depend on ruby18 packages(that you would then have to
> make)... but only as a temporary stopgap measure. The packages need
> to clearly identify that they are a transition package only.  There
> will be no ongoing "CSWruby" package, after transition is complete.

I think this will need to get tied into the system with alternatives
too, so that we can setup /opt/csw/bin/ruby -> ruby18, etc.  I'll also
need to handle migrating gems for the ruby18 packages since the
$libdir will change when I add a suffix to everything.  A post install
script should handle this nicely.

> Sound okay?

I'm good with it, provided the caveats above are acceptable.  Once
gcc4 is back in action I can tackle this.

/me goes off to work on a new libmpfr.

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

More information about the pkgsubmissions mailing list