Hello !
On Mon, Jun 20, 2011 at 4:59 AM, Antonio Terceiro
<terce...@softwarelivre.org> wrote:
> I've just updated gen-ruby-trans-pkgs in gem2deb to do The Right Thing,
> and will upload a new version of gem2deb soon.
Please wait ;-)...
> Please double check your packages and make sure your new ruby-foo
> `Breaks: libfoo-ruby, libfoo-ruby1.8` instead of Conflicts: (and make
> sure that's a versioned Breaks: in the same way we have done until now
> with versioned Conflicts:)
Hmmmm... I also thought of that, but I'm unsure now. Break will only
ensure that the packages are not configured at the same time, while
Conflict will ensure they are not unpacked at the same time. Imagine
that we have the old libruby-foo1.8 and the new ruby-foo.
libruby-foo1.8 have files in /usr/lib/ruby/1.8, while the newer has
files in /usr/lib/ruby/vendor_ruby. The problem is that if the old
libruby-foo1.8 is unpacked but unconfigured for some reason while
ruby-foo is installed and configured (which is allowed with Breaks,
but not with Conflicts), the new /usr/bin/foo executable (from
ruby-foo) will use preferably code from /usr/lib/ruby/1.8 (the old
code), which can lead to bugs really hard to detect if there ever was
a change between these two versions (such as an upgrade from lenny
with a new upstream version in wheezy !). The use of conflict avoids
that, at the cost of pain on the package maintainer.
What do you think about this ?
Cheers,
Vincent
--
To UNSUBSCRIBE, email to debian-ruby-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/BANLkTineDCaFrt7aHA-0m78ptQMQ=xv...@mail.gmail.com
