Ruby interpreter transitions
Ruby interpreter transitions are done in phases so that (hopefully) unstable is never broken. Examples of past transitions:
ruby2.5 transition (wiki page)
phase 0: get the new ruby in the archive (unstable|experimental)
Look at the debian/newruby script in the source package. it will adjust all the files under debian/ for the new rubyX.Y package.
phase 1: enable both interpreters in experimental
ruby-defaults gets uploaded telling gem2deb to build for both the old and the new ruby versions.
changes needed in ruby-defaults:
edit ruby_debian_dev.rb and add a new has_support_for block for the new interpreter.
do test rebuilds of all reverse-dependencies. take notes of what breaks, and report bugs with severity important.
open a transition bug against release.debian.org. using the following parameters for ben (the transition tracker tool), where A.B is the old version, and X.Y is the new one:
Affected: (.depends ~ /rubyA.B/ | .depends ~ /rubyX.Y/) & !.source ~ /^(rubyA.B|rubyX.Y|ruby-defaults|dislocker|epic5|graphviz|hivex|kamailio|klayout|kross-interpreters|libprelude|marisa|ngraph-gtk|notmuch|obexftp|redland-bindings|rubyluabridge|ruby-standalone|subtle|subversion|uwsgi|vim-command-t|weechat|robot-testing-framework|treil|vim|nbdkit)$/ Good: .depends ~ /rubyX.Y/ Bad: .depends ~ /rubyA.B/ & !.depends ~ /rubyX.Y/
The get the list of packages to be rebuilt you should do following:
call ben monitor passing the ben file above. With ben's output you get a list of packages separated by levels.
call reverse-depends -b -r unstable gem2deb to get the packages for the last level.
phase 2: enable both interpreters in unstable, rebuild/fix
tell the release team that you intend to enable builds against the new ruby version in unstable. provide information on which packages still FTBFS with the new Ruby enabled.
wait for an ACK from the release team.
upload the new ruby-defaults to unstable, binNMUs will be triggered automatically. Let the release team know the packages that you know will (not) build fine against the new ruby (and will not only build against the current default ruby) if possible.
packages get rebuilt/fixed with support for both the old ruby and the new ruby
ideally, what needs to fixed has to be fixed in a way that it won't need to be fixed again in the next transition (e.g. harcoded ruby versions need to be removed).
phase 3: new interpreter becomes the default
changes needed in ruby-defaults:
edit ruby_debian_dev.rb and swap the has_support_for block of the new and old interpreter. The new interpreter should come first.
run ./debian/newruby X.Y and it will replace the old version with the new one in several places in the package (where X.Y is the version of the new interpreter).
stage this in experimental first, ask people to test (at least in debian-ruby@lists.debian.org).
in special, test rebuilding all the stuff that links against the current default ruby version and make sure they can be binNMUed when the default really changes.
open a transition bug with the following ben file, where A.B is the old version, and X.Y is the new one:
Affected: (.depends ~ /rubyA.B/ | .depends ~ /rubyX.Y/) & !.source ~ /^(rubyA.B|rubyX.Y|ruby-defaults)$/ Good: .depends ~ /rubyX.Y/ | .depends ~ /librubyX.Y/ | !(.depends ~ /rubyA.B/ | .depends ~ /librubyA.B/) Bad: !(.depends ~ /rubyX.Y/ | .depends ~ /librubyX.Y/) & (.depends ~ /rubyA.B/ | .depends ~ /librubyA.B/)
tell the release team that you intend to switch the default in unstable before doing it; wait for an ACK from them.
upload the new ruby-defaults to unstable
binNMUs will be triggered for the packages that build against the default interpreter
phase 4: remove old interpreter from testing
changes needed in ruby-defaults:
edit ruby_debian_dev.rb and remove the has_support_for block for the old interpreter.
stage this in experimental first, ask people to test (at least in debian-ruby@lists.debian.org).
Open a transition:
open a transition bug against release.debian.org. using the following parameters for ben (the transition tracker tool), where A.B is the old version, and X.Y is the new one:
is_affected = (.depends ~ /rubyA.B/ | .depends ~ /rubyX.Y/) & !.source ~ /^(rubyA.B|rubyX.Y|ruby-defaults)$/; is_good = ! .depends ~ /rubyA.B/; is_bad = .depends ~ /rubyA.B/;
tell the release team that you intend to remove support for the old interpreter in unstable before doing it; wait for an ACK from them.
upload the new ruby-defaults to unstable
Then request binNMU for the packages marked as bad
When there are no bad packages left (i.e. the transition is done), request the removal from testing.
phase 5: remove old interpreter from unstable
just do it.
For ben files, we can use as reference the old ones:
https://salsa.debian.org/release-team/transition-data/-/tree/master/old