Re: Upcoming Ruby Plans
On 10/10 08:49, Jeremy Evans wrote:
> tl;dr:
>
> * Make ruby 2.4 default ruby version
> * Remove ruby 1.8, 2.1, 2.2
> * Remove ruby-do_* and ruby-swift-db-*
Here's a diff for ruby.port.mk reflecting the changes proposed:
* Remove support for ruby 1.8, 2.1, and 2.2
* Switch default version to ruby 2.4
* Remove support for ruby extconf and ruby setup CONFIGURE_STYLEs
The ruby extconf CONFIGURE_STYLE is currently only used by
databases/ruby-bdb, which will be removed soon (it was one of the
dependencies for the recently removed gonzui).
The ruby setup CONFIGURE_STYLE is currently only used by
devel/ruby-gems, which will also be removed soon.
Thanks,
Jeremy
Index: ruby.port.mk
===
RCS file: /cvs/ports/lang/ruby/ruby.port.mk,v
retrieving revision 1.90
diff -u -p -r1.90 ruby.port.mk
--- ruby.port.mk6 Jan 2017 16:03:54 - 1.90
+++ ruby.port.mk15 Oct 2017 21:43:24 -
@@ -5,15 +5,15 @@
CATEGORIES+= lang/ruby
# Whether the ruby module should automatically add FLAVORs.
-# If left blank, does so only for gem and extconf ports.
-.if ${CONFIGURE_STYLE:L:Mgem} || ${CONFIGURE_STYLE:L:Mextconf}
+# If left blank, does so only for gem ports.
+.if ${CONFIGURE_STYLE:L:Mgem}
MODRUBY_HANDLE_FLAVORS ?= Yes
.else
MODRUBY_HANDLE_FLAVORS ?= No
.endif
# This allows you to build packages for multiple ruby versions and
-# implementations using the same port directory for gem and extconf based
+# implementations using the same port directory for gem
# ports. It does this by adding FLAVORS automatically, unless FLAVORS are
# already defined or the port defines MODRUBY_REV to tie the port to a specific
# ruby version. For example, JDBC gem ports want to set FLAVOR=jruby, since
@@ -24,16 +24,15 @@ MODRUBY_HANDLE_FLAVORS ?= No
# If ruby.pork.mk should handle FLAVORs, define a separate FLAVOR
# for each ruby interpreter
.if !defined(FLAVORS)
-FLAVORS= ruby18 ruby21 ruby22 ruby23 ruby24
-. if !${CONFIGURE_STYLE:L:Mext} && !${CONFIGURE_STYLE:L:Mextconf}
-FLAVORS+= jruby
+FLAVORS= ruby23 ruby24
+. if !${CONFIGURE_STYLE:L:Mext}
+FLAVORS+= jruby
. endif
.endif
# Instead of adding flavors to the end of the package name, we use
# different package stems for different ruby versions and implementations.
-# ruby 1.8 uses the historical ruby-* package stem, newer ruby versions
-# use rubyXY-* and jruby uses jruby-*. In most cases,
+# Most ruby versions use rubyXY-* and jruby uses jruby-*. In most cases,
# PKGNAME in the port should be set to the same as DISTNAME, and this
# will insert the correct package prefix.
FULLPKGNAME?= ${MODRUBY_PKG_PREFIX}-${PKGNAME}
@@ -46,39 +45,29 @@ FULLPKGNAME?= ${MODRUBY_PKG_PREFIX}-${P
SUBST_VARS+= GEM_BIN_SUFFIX GEM_MAN_SUFFIX
FLAVOR?=
-# Without a FLAVOR, assume the use of ruby 2.3.
+# Without a FLAVOR, assume the use of ruby 2.4.
.if empty(FLAVOR)
-FLAVOR = ruby23
+FLAVOR = ruby24
.endif
# Check for conflicting FLAVORs and set MODRUBY_REV appropriately based
# on the FLAVOR.
-.for i in ruby18 ruby21 ruby22 ruby23 ruby24 jruby
+.for i in ruby23 ruby24 jruby
. if ${FLAVOR:M$i}
MODRUBY_REV = ${i:C/ruby([0-9])/\1./}
-.if ${FLAVOR:N$i:Mruby18} || \
-${FLAVOR:N$i:Mruby21} || \
-${FLAVOR:N$i:Mruby22} || \
-${FLAVOR:N$i:Mruby23} || \
+.if ${FLAVOR:N$i:Mruby23} || \
${FLAVOR:N$i:Mruby24} || \
${FLAVOR:N$i:Mjruby}
ERRORS += "Fatal: Conflicting flavors used: ${FLAVOR}"
.endif
. endif
.endfor
-
-.if ${FLAVOR:Mruby18}
-# Handle updates from older ruby 1.8 ports that didn't use the ruby18
-# FLAVOR by adding a @pkgpath entry to the PLIST.
-SUBST_VARS+= PKGPATH
-PKG_ARGS+= -f ${PORTSDIR}/lang/ruby/ruby18.PLIST
-.endif
. endif
.endif
-# The default ruby version to use for non-gem/extconf ports. Defaults to ruby
-# 2.3 for consistency with the default ruby23 FLAVOR for gem/extconf ports.
-MODRUBY_REV?= 2.3
+# The default ruby version to use for non-gem ports. Defaults to ruby
+# 2.4 for consistency with the default ruby24 FLAVOR for gem ports.
+MODRUBY_REV?= 2.4
# Because the jruby FLAVORs use same binary names but in
# different directories, GEM_MAN_SUFFIX is used for the man pages to avoid
@@ -103,19 +92,14 @@ MODRUBY_SITEDIR = jruby/lib/ruby/site_ru
RAKE= ${RUBY} -S rake
RSPEC= ${RUBY} -S spec
RUBY= ${LOCALBASE}/jruby/bin/jruby
+MODRUBY_RUN_DEPENDS= lang/jruby
-. if ${CONFIGURE_STYLE:L:Mext} || ${CONFIGURE_STYLE:L:Mextconf}
+. if ${CONFIGURE_STYLE:L:Mext}
ERRORS += "Fatal: Ruby C extensions are unsupported on JRuby"
-. else
-MODRUBY_RUN_DEPENDS= lang/jruby
. endif
.else # not jruby
-. if ${MODRUBY_REV} == 1.8
-MODRUBY_PKG_PREFIX =
Re: Upcoming Ruby Plans
On 10/12 09:33, vtamara wrote:
> In general I think these are good plans. I use to develop applications on
> Ruby on Rails, and I try to keep always with the latest version of the gems
> (since I use bundler I don't use the gems packed for OpenBSD) So these are
> good plans for me.
>
> Besides that, and thanking your hard work maintaining recent Ruby on
> OpenBSD, I would like to ask you:
> - How to use chroot with unicorn ?
>
> I have not been able to find documentation about it, except notes in
> changelogs.
It is mentioned in the unicorn documentation for the Unicorn::Worker#user
method.
I run my unicorn processes using unicorn's fork+exec support, chrooting,
priv dropping, then pledging. I use nginx as the main webserver, and
have it send requests to unicorn using a unix socket. In my unicorn
config files, I have code similar to:
require 'pledge'
listen '/var/www/sockets/app.sock'
worker_exec true
after_worker_ready do |server, worker|
server.logger.info("worker=#{worker.nr} ready")
worker.user('_app', '_app', true)
Pledge.pledge('rpath prot_exec unix')
end
One of the issues you will run into is you need to make sure that all
libraries necessary are loaded before chroot. This can be tricky if
you are using libraries that use autoload, which you are because rack
uses autoload.
Thanks,
Jeremy
Re: Upcoming Ruby Plans
In general I think these are good plans. I use to develop applications on Ruby on Rails, and I try to keep always with the latest version of the gems (since I use bundler I don't use the gems packed for OpenBSD) So these are good plans for me. Besides that, and thanking your hard work maintaining recent Ruby on OpenBSD, I would like to ask you: - How to use chroot with unicorn ? I have not been able to find documentation about it, except notes in changelogs. Again, thanks a lot. Blessings. El 2017-10-10 22:49, Jeremy Evans escribió: tl;dr: * Make ruby 2.4 default ruby version * Remove ruby 1.8, 2.1, 2.2 * Remove ruby-do_* and ruby-swift-db-* This message may be a little long, but if you are interested in ruby on OpenBSD, I'd like to get some feedback. I plan on preparing for these changes over the next few weeks, and commiting them during p2k17. Now that ruby 2.4.2 has been released, I plan to switch the default ruby version in the ports tree from 2.3 to 2.4. I'll be doing bulk builds of all ruby ports before and after switching to hopefully catch all the necessary bumps. In late August I worked on getting the remaining ports that depended on ruby 1.8 working on a modern version of ruby, and getting OKs to remove a couple ports that couldn't be upgraded and were no longer needed (gonzui and puppet-dashboard). There shouldn't be any remaining ports that depend on lang/ruby/1.8, other than some old ruby libraries: * databases/ruby-bdb (dependency of gonzui) * devel/ruby-gems (included in ruby 1.9+) * devel/ruby-rake (included in ruby 1.9+) So I plan on removing these ports and then removing ruby 1.8. Upstream support for ruby 2.1 was dropped completely in March, so I plan on also removing ruby 2.1 per our usual ruby support policy. When I first proposed our current ruby support policy in August 2015, there was a greater need to support older ruby versions. Since then, the last couple ruby versions have had fewer backwards incompatible changes, so there is less reason to continue to supporting old versions. Plus, honestly I don't want to backport security patches to versions not supported upstream. So, with that in mind I'd like to update our ruby support policy to the following: 1) All upstream versions in normal maintenance phase are supported, with C extensions built for each version. 2) Once an upstream version enters security maintenance phase, it remains in the ports tree, but C extensions are no longer built for it. 3) 6 months after the upstream version enters security maintenance phase, it is removed from the ports tree. Currently, this would have the effect of also removing ruby 2.2, since it has been over 6 months since ruby 2.2 entered security maintenance phase (which happened on March 28, 2017 with the release of ruby 2.2.7). There are currently a couple of ruby ports (ruby-augeas and ruby-libvirt) that are built for ruby 2.2 and not ruby 2.3, those will need to be dealt with before ruby 2.2 can be removed. There are quite a few ruby database driver ports in the tree that are no longer needed: * ruby-data_objects * ruby-do_mysql * ruby-do_postgres * ruby-do_sqlite3 * ruby-swift-db-mysql * ruby-swift-db-postgres * ruby-swift-db-sqlite3 These ports are all dead upstream. They used to be usable with databases/ruby-sequel, but support for them was dropped in a recent Sequel version, and there is nothing in the tree that uses them. The data_objects and do_* ports were used by DataMapper and were reasonably popular at one point, but pretty much nothing in the ruby ecosystem still uses DataMapper anymore. The swift-db-* ports were never popular or widely used. I plan on removing these ports as well. There are a number of pure ruby gem ports in the tree that are not dependencies of anything else and have not been updated in many years. I would like to remove some of these ports as they do not add value. I don't have a list of such ports yet, this is probably something I'll research at p2k17. I appreciate any thoughts or comments on these changes. Thanks, Jeremy -- -- Dios, gracias por tu amor infinito. -- Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/ http://www.pasosdejesus.org/dominio_publico_colombia.html
Re: Upcoming Ruby Plans
On Wed, Oct 11, 2017 at 03:49:10AM +, Jeremy Evans wrote: > tl;dr: > > * Make ruby 2.4 default ruby version > * Remove ruby 1.8, 2.1, 2.2 > * Remove ruby-do_* and ruby-swift-db-* > > This message may be a little long, but if you are interested in ruby on > OpenBSD, I'd like to get some feedback. I plan on preparing for these > changes over the next few weeks, and commiting them during p2k17. > > Now that ruby 2.4.2 has been released, I plan to switch the default ruby > version in the ports tree from 2.3 to 2.4. I'll be doing bulk builds of > all ruby ports before and after switching to hopefully catch all the > necessary bumps. > > In late August I worked on getting the remaining ports that depended on > ruby 1.8 working on a modern version of ruby, and getting OKs to remove > a couple ports that couldn't be upgraded and were no longer needed > (gonzui and puppet-dashboard). There shouldn't be any remaining ports > that depend on lang/ruby/1.8, other than some old ruby libraries: > > * databases/ruby-bdb (dependency of gonzui) > * devel/ruby-gems (included in ruby 1.9+) > * devel/ruby-rake (included in ruby 1.9+) > > So I plan on removing these ports and then removing ruby 1.8. > > Upstream support for ruby 2.1 was dropped completely in March, so I plan > on also removing ruby 2.1 per our usual ruby support policy. > > When I first proposed our current ruby support policy in August 2015, > there was a greater need to support older ruby versions. Since then, > the last couple ruby versions have had fewer backwards incompatible > changes, so there is less reason to continue to supporting old versions. > Plus, honestly I don't want to backport security patches to versions not > supported upstream. > > So, with that in mind I'd like to update our ruby support policy to the > following: > > 1) All upstream versions in normal maintenance phase are supported, with >C extensions built for each version. > 2) Once an upstream version enters security maintenance phase, it >remains in the ports tree, but C extensions are no longer built for >it. > 3) 6 months after the upstream version enters security maintenance >phase, it is removed from the ports tree. > > Currently, this would have the effect of also removing ruby 2.2, since > it has been over 6 months since ruby 2.2 entered security maintenance > phase (which happened on March 28, 2017 with the release of ruby 2.2.7). > > There are currently a couple of ruby ports (ruby-augeas and > ruby-libvirt) that are built for ruby 2.2 and not ruby 2.3, those will > need to be dealt with before ruby 2.2 can be removed. > > There are quite a few ruby database driver ports in the tree that are no > longer needed: > > * ruby-data_objects > * ruby-do_mysql > * ruby-do_postgres > * ruby-do_sqlite3 > * ruby-swift-db-mysql > * ruby-swift-db-postgres > * ruby-swift-db-sqlite3 > > These ports are all dead upstream. They used to be usable with > databases/ruby-sequel, but support for them was dropped in a recent > Sequel version, and there is nothing in the tree that uses them. The > data_objects and do_* ports were used by DataMapper and were reasonably > popular at one point, but pretty much nothing in the ruby ecosystem > still uses DataMapper anymore. The swift-db-* ports were never popular > or widely used. I plan on removing these ports as well. > > There are a number of pure ruby gem ports in the tree that are not > dependencies of anything else and have not been updated in many years. > I would like to remove some of these ports as they do not add value. I > don't have a list of such ports yet, this is probably something I'll > research at p2k17. > > I appreciate any thoughts or comments on these changes. Thank you for the detailed explanation Jeremy. FWIW I agree with your plan. -- Antoine
