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

Philip Brown phil at bolthole.com
Fri Mar 18 20:35:14 CET 2011


Hi Ben,
Overall, packages look good. But there's an outstanding issue
reguarding gcc support.
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 :(
Feel free to redirect to maintainers if you wish.

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

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.

It is pretty short work, to make that config file auto-configuring,
since the file is itself ruby code.
In fact, I attach a diff for exactly how to do it, for the sparc
version. Took me about 5 mins.
(disclaimer: I'm no ruby programer, but seems like it should work)
If it doesnt come through mailing list, a copy is in my experimental
dir as rbconfig.patch.sparc
Converting it for x86 use should be trivial.

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

Some consideration points:


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

* So, the contrapositive of the above is worth mentioning: If we
autoswitch on $CC, then it allows large sites to make both camps of
users happy... and the site admins do not have to lift a finger to
make it happen. More people happy, and less work for them to do so.
Sounds like win/win ?

* If we autoselect on CC... site admins desiring to globally default
to gcc, could still theoretically globally set "CC=gcc" in
environments, which would have other benefits to their site as well.

* 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

For the record, both assumptions are wrong, in my $DayJob
I've tried to improve rbconfig.rb to be more accomodating of that, in
addition to the auto-selecting patch.


Please let me know what you think about it, given the above discussion points.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rbconfig.patch.sparc
Type: application/octet-stream
Size: 4808 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/pkgsubmissions/attachments/20110318/b70bcd5a/attachment-0001.obj>


More information about the pkgsubmissions mailing list