[csw-pkgsubmissions] newpkgs libruby18_1, ruby, ruby18, ruby18_dev(...)

[Ben Walton]

Excerpts from Philip Brown's message of Fri Mar 18 15:35:14 -0400 2011:

> Its unfortunate you did not choose to reply further to the thread on
> the maintainers list, and chose instead to just push the package. So
> now I have to address it here :(

I had nothing more to say on the matter at that time.  I find it
unfortunate that you use the release manager position as a tool to
force your viewpoint on this.  Discussion is fine, but sitting on
packages is not.

> (up front note: If you would like "the rest of the packages" pushed
> through, and we just hold
> ruby18_gcc4* for discussion purposes, I'm willing to do that)

Nope.  All or none, since not pushing this would be reducing existing
functionality.  I'm sticking with this approach (at least for now) as
it mimicks the existing behaviour.  The only change from previous
packages is that I'm now using a standard tool to implement the
switching behaviour.  I expect you not to sit on these for days while
you push your viewpoint.

> So... looking at how you have implemented ruby18_gcc4, it seems that
> all it does, is run alternatives on a *single* config file.  And the
> diffs between the two alternatives, are just 11 lines.

Yes, that's correct.

> It is pretty short work, to make that config file auto-configuring,
> since the file is itself ruby code.

And yet it's fragile in the face of change.  That makes maintenance
aggravating.  And since I've yet to see a use case, it's not time well
spent.

> So now, there are no more barriers of "how to autoswitch", or "how
> much work is it", but "should we do it or not?"

Well, I still see it as a pita on the backend...For no benefit that
any user has come forward about.  I implemented the switch in the
first place as there was a request to build with gcc4.  Thus, I am
responsive to real world requests.

> * Doing it via alternatives, means more work for the site admin, and
> less choice for the end user.  The admin MUST choose one or the other.
> and then the end user is stuck with their choice. (or, perhaps, they
> then have to file an official "change request",and justification, red
> tape, blah blah yuck)

The end user is the sysadmin from our perspective.  If the user wants
to circumvent these options, against the desire of the sysadmin, they
can overload their library search path and implement their own
rbconfig.rb.

> In large site installations, where some users may use Sun CC, and
> others use gcc, this is fatal; either for one set of users, or for
> that site using our packages. Most likely in toto; they would reject
> ALL our packages, if we are not large-site considerate.

When I see a bug filed (not by you to make a point), I'll entertain
it.  Until then it's speculation.

> * The existing configs, make two bad presumptions: They presume sun
> cc is definitely in /opt/SUNWspro/bin/cc, and that gcc is in
> /opt/csw/gcc4

The configs don't make assumptions.  They record facts.  Those facts
are the values that were passed by the build system to the be
recorded.  As we install sun cc at /opt/SUNWspro, that is the correct
value for rbconfig.rb to record.  Same with gcc.

> Please let me know what you think about it, given the above
> discussion points.

When I see bug reports, I'll reconsider.  Until then, it's more work
than it's worth.

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