> Your point of view: social ways to deal with incompatibility are superior to to technical ways to deal with incompatibility because the latter encourages deve

> Your point of view: social ways to deal with incompatibility are superior to to technical ways to deal with incompatibility because the latter encourages developers to be lazy about compatibility guarantees. Not quite. Social ways to deal with incompatibility are superior to the specific technical way that rubygems encourages. > Although it doesn't happen often, an app can break due to reliance on library bugs or unformalized/undocumented behavior/internals. Sometimes a newer version of a library has a regression that isn't found until it's released. > Yes we all know things like these ideally shouldn't happen, but they do. Is it a good idea to ignore the reality that things like this happen from time to time? I'm not ignoring that reality at all. I'm specifically encouraging point releases with backported bug-fixes. These happen all the time in dpkg-land. > According to the logic that supports your point of view, we should abolish protected memory as well. Extrapolation to extremes will destroy any rational argument, so I'll ignore this. > 2. It assumes that DPKG/RPM don't make life hellish for sysadmin and end users. > For the most part, DPKG/RPM works fine. For Ruby stuff, not so much. That would be the point. I'd also point out that it's not just a question of dpkg vs rubygems here. From a sysadmin's point of view, it's dpkg vs (rubygems + CPAN + PEAR + cabal + virtualenv/pip + maven + ...). > Suppose there's an app called frobnicator, and it works on foobar 1.0.x but not on foobar 1.2.x. Thanks to the fact that DPKG/RPM only supports installation of single versions, your distro can only package foobar 1.2.x but not 1.0.x. Now the user cannot use frobnicator at all because you insist on DPKG/RPM. That specific case isn't a problem, because you'd just package foobar 1.0.x and ignore 1.2.x completely. The problem comes when something else comes along that depends on 1.2.x but won't work on 1.0.x at all. That would be a case of either foobar's author not following version numbering convention, or a bug which can/should be patched. > How exactly is this better for the end user? If it's not, foobar's author is responsible. However, for the distro to be able to turn around and say "We value stability over all else, and we cannot provide this combination of packages while supporting a stable system, so we're not going to" is actually fairly awesome.