On 16.01.07 09:38:10, Vincent Fourmond wrote: > Andreas Pakulat wrote: > > today I need to install the qt3 ruby bindings while I already had the > > qt4 bindings installed. Unfortunately this deinstalled the qt4 bindings. > > I asked Richard Dale a kdevelop developer working with ruby very much if > > qt4 and qt3 ruby bindings cannot be installed at the same time and he > > told me that it is possible and that he does this all the time. > > > > So I'd like you to make this possible with the debian packages too, > > after all one can have Qt3 and Qt4 side-by-side and the same applies to > > the python bindings. > > This is a known problem. There are several aspects of it: > * the smoke library: I did need to tweak it quite a bit to be able, > say, to have both perl Qt3 bindings and Ruby Qt4 bindings on the same > machine. This is fixed and working. > * the ruby part of the bindings. > > The latter is unfortunately more delicate. Consider: folks using > qt3/ruby simply use a require 'Qt' statement in their program. On the > other side, to use version 1.4.6 of the qt4 ruby bindings, you also need > to use require 'Qt'. So obviously, they can't coexist on the same machine.
Understood, the python bindings had more luck here as Phil completely changed the naming scheme to follow the structure of Qt4. > The solution in qt4/qtruby 1.4.7 was to rename the appropriate files > so that now you need to say require 'Qt4', with a symlink for Qt.rb to > Qt3.rb or Qt4.rb. This works on a host-by-host basis, but it can't for a > distribution, since I can't simply provide an upgrade path. How shall I > handle the fact that Qt.rb is used to include completely different > functionalities ? For existing qt-ruby-packages in Debian there's probably a way to use the dependecies to force all packages to do a rebuild including the source change (I'm not that firm in this, but this has happened during the C++ ABI transitions). As for the stuff a user installed himself: IIRC you don't need to provide upgrade paths for that, its been the same thing for C++ ABI transitions, although there was no source-change necessary but this source change is trivial. Announcing it in the NEWS file should make everybody aware of the change. > The only answer I have, is to make Qt.rb point to Qt4.rb and issue a > warning that the support for it will be dropped later. Then, when this > package has been around for a while, I'll consider that all the people > did migrate, and I'll drop Qt.rb, and at this moment I'll remove the > conflict with Qt3 bindings. See above, I don't think it needs to be that long... But well, you're the maintainer, I'm just a user ;) > But that won't be for etch, as it *does* break the package. Of course not, I was not suggesting this to be done for etch. > If you want, as a temporary workaround, I can provide a new version of > the package without the conflict (and without Qt.rb) on my personal apt > repository. That would be great, although a source package would do it too, I have a build machine here ;) Andreas -- You will pay for your sins. If you have already paid, please disregard this message. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
