How to not collaborate with Debian (and upstream)
Lucas Nussbaum
lucas at lucas-nussbaum.net
Thu Aug 28 09:14:06 BST 2008
Hi,
First, Some background on Ruby/rubygems and Debian:
In the past (before sarge), the controversial decision to split the ruby
stdlib into several different packages was taken. This made the
installation of non-packaged ruby apps very hard, and was very unpopular
in the Ruby community. This was fixed a long time ago (maybe before
sarge, surely before etch), but some people in the Ruby community still
start shouting as soon as you mention Debian.
Rubygems is a very problematic issue, and unfortunately, the Ruby
community (esp. the part of the ruby community that does web apps)
relies more and more on it (there are many applications and libs that
are only distributed as gems). For more details, see Gunnar Wolf's talk
at debconf.[1,2]
[1] https://penta.debconf.org/dc8_schedule/events/241.en.html
[2] http://meetings-archive.debian.net/pub/debian-meetings/2008/debconf8/low/630_Bringing_closer_Debian_and_Rails.ogg
Also, the Ruby community tends to be quite bad at release management.
Rails users often prefer to use the latest git snapshot for everything,
even on production systems (that's probably why Neil decided to package
a rubygems git snapshot). Ruby, Rubygems and Rails releases often break
each other.
All of this makes it very difficult to work on those issues. And
clearly, we could use some help with talking with upstream to improve
this. I've also had contacts with the openSUSE ruby maintainer, who
shares exactly the same concerns.
Now, on this particular issue, the discussion on the launchpad bug was
clearly not the best example of well-behaved discussions between
developers. From my POV, the claims that the Debian packaging "crippled"
Rubygems, that I'm getting desparate, etc. clearly didn't help. I'm
sorry that the whole discussion happened like that, and I would have
preferred a more healthy discussion.
Besides the minor packaging strangeness in Neil's version (change of
packaging system, use of a git snapshot without saying it, copyright
problems, etc), the root problem is the hack around update-alternatives
to remove the possibility for rubygems to overwrite binaries when
several versions of the same gem are installed (possibly for different
versions of ruby).
* I don't think that this problem is grave enough to warrant maintaining
a long term divergence with upstream in Debian/Ubuntu.
* When discussed with upstream, they suggested a different solution
(warn the user when rubygems is going to overwrite a binary).
Answers to various comments from the thread:
On 27/08/08 at 20:35 -0400, Steven Harms wrote:
> This sounds more like 'How not to encourage anyone to help at all'.
> The tone of the comments in the bug are very confrontational when
> clearly all these people wanted was a functional package.
>
> They saw a package that didn't work for *anyone* and wanted to change
> it. They were not seasoned pro's, and I think this is just a
> testimate to the lack of a obvious process.
Rubygems, as packaged in Debian, is functional. Sure, some things are
disabled, like the fact that rubygems can't update itself anymore. Or
the fact that binaries from gems are installed in /usr/bin, possibly
overwriting binaries from other packages. If you found serious issues
with the package, please report them. But please stop the FUD.
On 27/08/08 at 18:41 -0700, Steve Langasek wrote:
> I don't think it's warranted to criticize people for finding
> OS-specific solutions for problems in Ubuntu. We're not here to try
> to solve all software problems for all distributions, we're here to
> make *Ubuntu* the best OS it can be - and healthy collaboration with
> upstream is an important part of that, but it's not the *only* thing.
I agree. The problem here is that:
* Rubygems' behaviour in Ubuntu will be different from upstream, and
this divergence will have to be maintained.
* This divergence, even documented, might be confusing for users (most
users probably don't know about update-alternatives)
* Nothing was done to try to find an upstream solution to this problem.
In the past, the Debian Ruby maintainers decided to diverge from
upstream by splitting stdlib into several packages. We got bitten very
badly. It looks like the same mistake is being done here.
--
| Lucas Nussbaum
| lucas at lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas at nussbaum.fr GPG: 1024D/023B3F4F |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20080828/93000d9d/attachment.pgp
More information about the ubuntu-devel
mailing list