motu-release will revert libgems-ruby to the old state.
sistpoty at ubuntu.com
Fri Aug 29 22:39:52 BST 2008
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
Using the alternatives mechanism was considered inappropriate and counter-
/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
Another non-technical concern was also raised against option 1): The advice of
developers in regards to the new gem handling was asked at  -- 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
Finally, in case this decision should not be acceptable to the involved
parties, feel free to escalate to motu-council.
Stefan - on behalf of motu-release.
More information about the Ubuntu-motu