Hi Vincent, Vincent Fourmond escreveu isso aí: > Hello ! > > On Mon, Jun 20, 2011 at 4:59 AM, Antonio Terceiro > <terceiro@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 ;-)... Oops, now it's too late. :-p We can always undo with a new upload if that's the case. :) > > 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), Vendor dirs have precedence over the interpreter's library directory: terceiro@morere:~ (home)$ ruby1.8 -e 'puts $:' /usr/local/lib/site_ruby/1.8 /usr/local/lib/site_ruby/1.8/i486-linux /usr/local/lib/site_ruby/1.8/i386-linux /usr/local/lib/site_ruby /usr/lib/ruby/vendor_ruby/1.8 /usr/lib/ruby/vendor_ruby/1.8/i486-linux /usr/lib/ruby/vendor_ruby /usr/lib/ruby/1.8 /usr/lib/ruby/1.8/i486-linux /usr/lib/ruby/1.8/i386-linux . terceiro@morere:~ (home)$ ruby1.9.1 -e 'puts $:' /usr/local/lib/site_ruby/1.9.1 /usr/local/lib/site_ruby/1.9.1/i486-linux /usr/local/lib/site_ruby /usr/lib/ruby/vendor_ruby/1.9.1 /usr/lib/ruby/vendor_ruby/1.9.1/i486-linux /usr/lib/ruby/vendor_ruby /usr/lib/ruby/1.9.1 /usr/lib/ruby/1.9.1/i486-linux So in this case we are lucky to be replacing a package by installing files in a directory with higher precedence in the $LOAD_PATH, so Breaks: is good enough for us. -- Antonio Terceiro <terceiro@softwarelivre.org> http://softwarelivre.org/terceiro
Attachment:
signature.asc
Description: Digital signature