Bug#596574: unblock: ruby1.9.1/184.108.40.206-1 libgems-ruby/1.3.7-2
On Mon, September 13, 2010 14:12, Lucas Nussbaum wrote:
> On 13/09/10 at 13:19 +0100, Adam D. Barratt wrote:
>> On Sun, September 12, 2010 18:27, Lucas Nussbaum wrote:
>> > The rubygems1.9.1 package used to be built from the libgems-ruby
>> > package. But Ruby 1.9.2 broke it, so we decided to switch to using
>> > 1.9.2's rubygems for 1.9.X.
>> > That requires dropping the 1.9 package from libgems-ruby, and making
>> > changes to the ruby1.9.1 package to add the rubygems files to the
>> > ruby1.9.1 package. (full discussion in #588125)
>> > Additionally, a common complaint from rubygems users was addressed, by
>> > allowing a workaround to do "gem update --system". (Done in both
>> > packages).
>> Why was this uploaded with an urgency of high?
> Because I have little doubt that the package is of better quality than
> the one currently in testing, and I'd like to maximize testing of the
> package by having it migrate ASAP.
Testing in unstable is also useful; mentioning that in the changelog would
have been helpful, at least imho.
>> One of the changes in debian/rules isn't mentioned in the changelog:
>> -include /usr/share/quilt/quilt.make
>> +include /usr/share/cdbs/1/rules/patchsys-quilt.mk
> Should I upload a fix?
If there's a good reason the change was made, that's fine. I wasn't able
to find an explanation in the changelog, so I queried it.
>> > Then, ruby1.9.1 220.127.116.11-1.
>> Already unblocked by Luk as part of the "security fixes unblock" set,
>> aged to 20 days.
> I don't understand the reason for that. I think that we agree that this
> version is better than the previous one. Why do you prefer to reduce the
> opportunity for testing by not letting it migrate now?
I assume that was "plural you". :)
>From <[🔎] 4C8DBE97.email@example.com>:
| > unblock ruby1.9.1/18.104.22.168-1
| unblocked and aged to 20 days due to massive changes
>From a quick look at the diff, much of the changes appear to be
auto-generated stuff in enc/trans/ and ext/ripper; are either/both of
those used in the packages?