motu-release will revert libgems-ruby to the old state.

[Stefan Potyra]

Hi,

first off, this was not an easy decision. It didn't happen so far yet, that 
motu-release had to decide if an upload should indeed get reverted, and hence 
this decision was done only with consent among all motu-release members. The 
key factor in regards to this decision was if this upload does work towards 
making an improvement in regards to the intrepid-release, or if it did in fact 
result in the opposite, hence making it unfit for release.

The following options were considered:
1) do not interfere,  regressions/bugs are not grave enough to warrant an 
action of motu-release
2) revert the upload, either by archive admin intervention, or by uploading 
the old version with a higher version number.
3) revert the packaging back to the old version, but keep the svn snapshot 
(adjusting patches of the old packaging as needed)
4) Issue a one week deadline to Matthiaz/Neil to revert the packaging back to 
the old version, keeping the svn snapshot, otherwise falling back to 2.

Since the svn snapshot made some patches unnecessary, option 3) was eliminated 
because it could cause regressions in a reversion upload from motu-release, 
whereas 4) seemed to address this concerns better.

In order to find out, if 1) was a possible way, the possible regressions of 
gem handling in the change were examined compared to the previous package. 
This lead to the following findings:

Executables of gems get symlinked via the alternatives mechanism to 
/usr/local/bin.

Using the alternatives mechanism was considered inappropriate and counter-
intuitive.

/usr/local/bin is the first entry in $PATH, so executables installed there 
override any executables installed from Debian/Ubuntu packages.

As a result, this can lead to problems in case there is a name clash between a 
binary shipped from an Ubuntu package and a binary installed from a gem. Among 
the problems of non-determinism and possible failing behaviour of Ubuntu-
packages in case such a name-clash occurs, this situation is both hard to 
detect for a user/sysadmin, but also hard to fix without modifying 
/usr/local/bin in the first place (which however counter-acts the idea of the 
new gem handling).

Especially the possible security problems arising from this approach (the mail 
from Stephan Hermann with imagemagick shipped by a gem served as an example in 
the motu-release discussion, especially since imagemagick is often called by 
web applications), was considered a critical enough issue to eliminate option 
1).

Another non-technical concern was also raised against option 1): The advice of 
developers in regards to the new gem handling was asked at [1] -- something 
which motu-release unambigously encourages -- but was obviously ignored when 
doing the upload in question.

In order to find out, if patches from the new packaging should be kept, the 
diff to the old version was examined. 
The only noteworthy patch that was found, that doesn't fall under the catagory 
gem-handling, was a modification of the libgems updating mechanism. In 
contrast to the old version, this patch modifies the libgems package to call 
"apt-get install rubygems[version]" instead of printing a message to the user 
as the old package did. This approach was considered buggy as well, since it 
fails when apt-get is concurrently executed and is a no-operation in case
the package list is not up to date.

Finally, the discussion came down to choose between option 2) and 4). While 
importing a svn-snapshot wasn't considered a problem (since it was done before 
FeatureFreeze), motu-release tried to find out arguments why this was done in 
the first place. motu-release was convinced that this was done only in regards 
to the new gem handling. 
Likewise, the mislabeling of a svn-snapshot as non-technical argument was 
considered a bad practice. 
As a result it was decided to go for option 2).

In this regard, motu-release found that unaccepting uploads is not possible 
with soyuz. To determine whether an epoch should be added, or rather a 
complicated version number should be used, motu-release contacted Lucas to 
find out if an epoch could be added to the debian package as well. However 
since Lucas stated that he was only the co-maintainer, and the maintainer 
would not very likely to agree to such a change, using a mangled version 
number was decided upon.

As a result, motu-release will upload a reverted package within 24 hours. 
After that upload, libgems-ruby is free to be modified following the freeze 
rules again.

Finally, in case this decision should not be acceptable to the involved 
parties, feel free to escalate to motu-council.

Cheers,
    Stefan - on behalf of motu-release.