Ciao Luca, On Wed, Aug 29, 2007 at 11:06:17PM +0200, Luca Capello wrote: > Hi Matthias! > > On Wed, 29 Aug 2007 08:04:30 +0200, Matthias Schneider wrote: > > --- Luca Capello <luca pca it> schrieb: > >> First of all, I started to investigate because on a clean and > >> up-to-date sid (created as described at [1]) ekiga-snapshot doesn't > >> depend on libopal-cvs and indeed: > [...] > >> root gismo:/# su luca > >> luca gismo:/$ ekiga-snapshot > >> ekiga-snapshot: error while loading shared libraries: libopal.so.2.3: \ > >> cannot open shared object file: No such file or directory > >> luca gismo:/$root gismo:/# > >> ===== > >> > >> What's strange is the following: > >> ===== > >> luca gismo:~$ dpkg-shlibdeps /usr/bin/ekiga-snapshot > >> dpkg-shlibdeps: warning: could not find any packages for libopal.so.2.3 > >> dpkg-shlibdeps: warning: unable to find dependency information for \ > >> shared library libopal (soname 2.3, path libopal.so.2.3, dependency \ > >> field Depends) > >> dpkg-shlibdeps: failure: open new substvars file \ > >> debian/substvars.new': No such file or directory > >> luca gismo:~$ > > This *is* a problem. Right. And even having looked to it, I don't (yet) see why this happens and thus how to fix it. I'm open to suggestions, but this will need further debuging why this happens to get it sorted out. > >> I'd say that libopal-cvs is definitively broken. > > > > No, it is not. Actually a desired behaviour, libavcodec.so is > > loaded dynamically on runtime, and if it is not found, some of > > ekiga's codecs (i.e. MPEG4 P 2, H.264, H.263+) will simply be > > deactivated (like you wrote in your first email), but ekiga will br > > completely functional. > > As I said, I'm not a library expert, so thank you for the > explanation. > > > So I would say points 1) and 2) of your original email is normal > > behavior. The debug output just tells you where it looks for > > libavcodec.so and if it finds it. > > Perfectly understandable. Kilian, IMHO libopal-cvs should at least > Suggests: libavcodec1d, maybe even Recommends:. Yes, the problem however is the multitude of Packages providing it. I need to make a list and add that unless you have one. > > The same should be true for x264, ekiga/opal executes a helper > > process that is dynamically linked to x264. In case that execution > > fails, H.264 should simply be deactivated, and ekiga should start up > > anyway... > > I didn't look into the code (most of which I cannot understand), but > I'm a bit surprised: shouldn't x264 acts the same as libavcodec? I > mean, without libavcodec the H.264 codec is deactivated, thus I don't > see the point in having libx264 installed while it's not used. So, > I'd like libopal-cvs to not depends on, but only suggests or > recommends, all the libraries/codecs which need libavcodec. That's something with the way the linking is done right now. If the plugin does depend on it (instead of fully dynamically load it when provided and needed), it'll show up in the Depends. > Please pay attention that if libopal-cvs depends on libx264, this > creates a big problem for Debian, since libx264 has patent issues (and > thus ATM cannot be redistributed in Debian, maybe in non-free [1]). > This causes libopal-cvs (or any other official libopal depending on > libx264) to be put in contrib, according to [2]. The *-cvs variant is not intended for Debian. It's an external repository. The official Debian version will not have X.264 (and just for the record, doesn't have iLBC either for the obvious same DFSG-reason). -(snip)- > [1] it seems quite strangely, however, that the package has been > removed if it could have been available in non-free it could not: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423250 -- Best regards, Kilian
Attachment:
signature.asc
Description: Digital signature