Re: Bits from the Ruby team: switching to Ruby 1.9 and trasition to new policy
On 04/06/12 at 19:59 +0100, Adam D. Barratt wrote:
> > # What it means for package maintainers
> >
> > If you maintain a program that is written in Ruby and it is not
> > compatible with Ruby 1.9, then you should change shebang lines to use
> > `/usr/bin/ruby1.8` instead of `/usr/bin/ruby`, and make your package
> > depend explicitly on `ruby1.8`.
>
> Was any of this communicated to package maintainers beforehand?
Yes, but not as bugs, as it was difficult to identify packages that
needed fixing without false positives. See
http://lists.debian.org/debian-ruby/2012/04/msg00066.html for the mail
informing packages maintainers. I think there was another such mail, but
I'm not sure now.
> Although I don't know offhand if the Ruby bindings produced by gdal are
> inherently not compatible with Ruby 1.9, I do know that the
> ruby-defaults switch has made it FTBFS whilst involved in a transition
> and I can't see any relevant bugs filed. (I assume there are more such
> issues, this is just one I'm aware of because of the transition
> involvement.)
>
> > The easiest way to support the new Ruby policy is to use gem2deb [3],
> > our new Ruby packaging helper. It is not mandatory, though, and as long
> > as packages follow the new Debian Ruby policy, everything is good.
> >
> > [3] http://packages.debian.org/gem2deb
>
> Based on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675974 , it
> looks like gem2deb + ruby 1.9.1 breaks dh_ruby-using packages. Is this
> a known issue?
It was not known before today (unfortunately the gem2deb test suite did
not include any UTF-8 control files). Fixed now in gem2deb 0.2.15 (just
uploaded).
> > # Current state of the transition to the new policy
> >
> > The Debian/Ruby Extras team [4] has transitioned all its packages
> > (except for some that are still stuck in NEW) to support the new policy
> > (i.e. changed package names and install locations). There are however
> > still quite some source packages not maintained by the team that still
> > provide binary packages called lib$foo-ruby{,1.8,1.9.1} (52) or install
> > in /usr/lib/ruby/{,1.8,1.9.1} (91). See also [5] for an overview (note
> > that the list contains a few false positives). The Debian/Ruby Extras
> > team is willing to help out with updating the packages to the new
> > policy. We will start filing bugs against non-migrated packages very
> > soon.
>
> That's over 150 packages, which sounds like quite a lot to have
> outstanding if this is intended to be "the way things are" for Wheezy.
> >From what I've seen so far, this doesn't immediately sound like
> something that would qualify for freeze exceptions for the affected
> packages.
We did that transition in an unusual way. We first switched to a new
packaging helper (gem2deb) and ported all of the team's packages to that
new helper. gem2deb runs test suites with both Ruby versions, so its a
good way to check for brokenness.
But now, the last step is to switch to 1.9.x as default, instead of 1.8.
Yes, it's late in the release cycle. But:
(0) the switch to 1.9.x as default Ruby is very important for us, since
it is the final achievement of most of the work done during that
cycle
(1) we are not frozen yet
(2) looking at the current number of RC bugs, it seems unlikely that we
release in July
(3) most of the packages that need fixing are leaf packages, or packages
for which the Ruby bindings can be easily disabled
I will do an archive rebuild tomorrow with the updated gem2deb, and try
to get a better overview of FTBFS caused by this change.
Lucas
Reply to: