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

Ben Walton bwalton at opencsw.org
Sat Mar 19 01:37:25 CET 2011


Excerpts from Philip Brown's message of Fri Mar 18 17:10:17 -0400 2011:

> Ah. I was initially pondering how you were saying that, since
> current packages do not use alternatives. Some explaination would
> have been useful here. After doing my own poking, it would seem that
> current ruby package supports gcc only. I was not aware(or at least,
> have forgotten) that the current package was in violation of our
> usual standards.

The current package ships with rbconfig.rb.SUN and rbconfig.rb.GCC4
and a symlink pointing (by default) at the SUN version.  There is the
a tool called cswrbconfig that toggles between them...a ruby specific
alternatives setup.

> As such, are you changing the default behaviour, if a person does only
> "pkgxxxx upgrade ruby".

Nope.  It will behave the same by default as the old package.  The
only thing they'll need to do is install the -gcc4 package if they
want the extra file and symlink toggle...a notice about this change
was already sent to users at .

> how was it done previously?

See above.

> I have just told you that your package will not function properly, in
> my real-life large site installation. This is not a hypothetical. This
> is REAL WORLD USE.

And I sketched out a solution to this that lets every single users on
the system use different values if they want to.

> And you have told me that you are going to ignore that fact, simply
> because it is *my* site?

No, it has nothing to do with what site you're at, Phil.  It's the
fact that you've taken an issue that wasn't even on the radar until
three days ago when I raised a question on the list to now block a
package because it's not done in the way you prefer it to be.

My issue is with your methods, not your site.

...And, if I really thought it was the best way a to do it, I'd simply
go change it and come back.  I'm not convinced that it's completely
sane.  I'm not done thinking about it; It's worth further
consideration.  I am, however, done this package for now and therefore
pushed it to release.  If it _needs_ changes in the future, it'll get
them.  In the meantime, I need to figure out how to shoehorn an apache
update down pkg-get's throat...that is worth more of my time currently
than this non-issue.

Thanks
-Ben

[1] If you look for ENV['CC'] and expect an unqualified binary to make
    the choice, you're opening the issue to wider problems.  You're
    then going to assume that cc is sun pro when it need not be.  Same
    for gcc.  Do you assume it's version 4?  The options in the other
    variables currently assume that's the case, but what if this
    changes.  The current mechanisms are using known working
    combinations of settings.
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302



More information about the pkgsubmissions mailing list