Ruarí's thoughts

The problem it would seem is that the person doing the packaging is using various automated tools and scripts to work out Opera's dependencies. Part of this I would imagine is using ldd (or a similar tool) on the contents of '/usr/lib/opera/'. However, this will also pick up the dependencies for files such as liboperagtk.so and liboperakde4.so. Those two files are included to adjust Opera's default styling and make us us look native if the various KDE and/or Gtk libraries are present. Or to put it another way, they are entirely optional. Opera will run just fine without KDE or Gtk libraries, instead using its own toolkit.

Note: The Opera 12.00 snapshots actually include three files of this kind now, liboperagtk2.so, liboperagtk3.so and liboperakde4.so. The extra Gtk file being used to do Gtk3 styling. So presumably a packager who uses such a system might end up thinking we depend on kdelibs, Gtk2 and Gtk3 in the future.

So how should a packager work out the dependencies for Opera? Use ldd (or a similar tool) only on '/usr/lib/opera/opera', you needn't even consider the operapluginwrapper or operaplugincleaner, as they require nothing over and above the main executable.

There is one other additional thing you may wish to consider and that is GStreamer, which Opera uses for HTML5 Video. Our official Opera deb and rpm packages depend on files from the GStreamer Multimedia Framework, the Base Plugins package and the main Good libraries. Since we consider HTML5 Video to be a key feature of graphical browsing (much like images) we have selected a hard dependency on the files we need and hence would generally suggest you do the same. If however you find this conflicts in some way with the packaging policy of your distro, you could alternatively consider it an optional dependency as long as you can easily inform the user that without this package Opera will not be feature complete.

P.S. And yes, I have sent the packager in question an email with these tips.