Le 14/10/2019 à 18:37, Koichiro Iwao a écrit :
On Tue, Sep 17, 2019 at 07:34:27AM -0400, Steve Wills wrote:
Hi,
On 9/17/19 2:40 AM, Mathieu Arnold wrote:
What we are all trying to say is that adding flavors for ruby will have
a big impact on build time and ressources required for building.
If all you want is to have ruby flavors for the kicks of it, then I am
glad to tell you that no, it will not be done.
Now, the question is, why would someone need to have ruby flavors?
The answer cannot be "because it should be fun" or "there is no reason
there should not be".
Give us a real reason about why it would be required.
We have multiple versions of Ruby, we should provide the gems for each
version. Right now, there is no way for users of Ruby 2.4 to install gem
packages except to change the default ruby and then build their own
packages. We want people to have fewer reasons to build their own packages,
not more.
We keep the latest Ruby as not default because it tends to have more bugs
and gems lag, and the older version of Ruby is available because some gems
tend to lag really badly. So, users do have legitimate reasons for using the
non-default versions of Ruby. Also, upstream supports latest and two
versions back.
It wasn't until Ruby 2.6 was out that GitLab even supported 2.5, to give
just one example.
So, we have those versions of Ruby, and they should be usable, and that
includes installing gems via pkg.
There's the point that maybe we should only package gems that are needed by
other things, which I can understand, but don't know if I necessarily agree
with, because then you have users confused on what the "right" way to
install a gem is. "Oh, this one is packaged because something else in ports
needs it, so use the pkg, but this other one isn't packaged, so you have to
use gem."
And I'd think the same applies to python modules or perl modules, etc. One
could ask, why not provide flavors for all versions of python, that is, 3.5,
3.6 and 3.7, along with the 2.7 ones as well, but to me that doesn't seem
quite necessary because the compatibility is better there, as far as I can
tell. But, I wouldn't be opposed to it personally, if someone did make the
argument in favor of it. Same with Perl and especially things that depend on
Java.
But that's all beside the point, really.
Steve
Hello again everyone,
I'm sorry I cannot express my thoughts correctly in English and I clould not
explain why flavors for Ruby required but swills explained far better than me.
Based on his explanation, will it be a valid reason to introduce flavors
on Ruby ports?
Ruby use semantic versioning since version 2.1.0, unless there is Ruby 3
version release there is no reason to have flavors in FreeBSD for Ruby.
Also, I don't even understand why there is several Ruby version in the
ports tree since Ruby 2.6 is (as guaranteed by semantic versioning)
retro compatible with 2.5, 2.4 and so on. Ports ruby24, ruby25 should be
deleted.
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"