Comment 59 for bug 145267

I'd like to file a bug against the communication in this report. Also, there is a caesura at the end leading to a breakup that is hard to follow.

Actually, here's an explanation to save others time:
1. Neil Wilson uploads a package
2. Lucas Nussbaum and Scott Kitterman and others disagree with details about the packaging
3. They discuss it in ubuntu-devel here: https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026212.html
4. A bug is filed against the uploaded package by Scott Kitterman: https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/262063
5. The uploaded package is reverted by the powers that be
6. The problem will not be fixed this cycle :(

As Scott Kitterman says above, there could be a long useless discussion about who is being more arrogant or dense or passive-aggressive. In general I see a lot of confusion about priorities in the Debian packaging system, as well as some pervasive confusion about the relationship of Debian policy to the *two different packaging systems* (I think Lucas Nussbaum and Neil Wilson both understood the precise issues, but some others got confused). The best thing to do is start planning for the next cycle on this, especially to make certain process decisions and get certain clarifications and commitments now.

I would suggest:

0. Clarify that "don't use gems" isn't a solution. Gems are used for different reasons than Deb packages.
1. Clarify that Debian policy affects the installation of the rubygems files, but not "the installation of gem files by rubygems".
2. Clarify that Debian policy frowns on installing _any_ rubygems files (that is, files carried by the Apt package) into /usr/local/ AND that there is a resistance to simply adding /var/lib/gems/1.{8,9}/bin to the path. The first is clear but not done by any proposed Rubygems Deb package (right?). The argument for the second is that gem binaries could then supercede system binaries. We need to clarify whether this is really beyond the pale, since the decision to install a gem is an administrator decision, not a user decision. In other words, installing a gem is equivalent to installing a source package except that gems allow for quick uninstall.
3. Commit that *if* Debian rejects movement toward a solution, Ubuntu _can_ maintain its own solution.
4. Clarify what if any changes are required/suggested for upstream
5. Commit that *if* upstream is unresponsive or uninterested, Ubuntu _can_ maintain its own patches.

I'd like to help make this happen for the next cycle and to get a package candidate released into a PPA that Intrepid users can be directed to.