Re: [Ekiga-devel-list] ekiga-snapshot Debian package

[Luca Capello <luca pca it>]

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.

>> 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:.

> 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.

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].

> So your crashes have absolutely nothing to do with ffmpeg or
> x264. The casue is always your gnome problem...

And I completely agree here, in fact my post was specifically about
the Debian packages, nothing about my crashes (which I reported on the
"old" thread).

> Why is the libavcodec library's file called libavcodec.so.1d ? How
> shall the loader know that? I was under the impression that usually
> we have a symlink libavcodec.so pointo to the correct library...

Well, I wouldn't say so on Debian, libavcodec.so is in the -dev
package:
=====
luca gismo:~$ dlocate libc.so
libc6-i386: /emul/ia32-linux/lib/libc.so.6
libc6: /lib/libc.so.6
libc6-dev: /usr/lib/libc.so

luca gismo:~$ dlocate libavcodec.so
libavcodec-dev: /usr/lib/libavcodec.so
libavcodec1d: /usr/lib/libavcodec.so.1d.51.38.0
libavcodec1d: /usr/lib/libavcodec.so.1d

luca gismo:~$ dlocate libpt.so
libpt-cvs: /usr/lib/libpt.so.1.11.3
libpt-cvs: /usr/lib/debug/usr/lib/libpt.so.1.11.3
libpt-cvs-dev: /usr/lib/libpt.so
libpt-cvs-dev: /usr/lib/libpt.so.1.11
libpt-cvs-dev: /usr/lib/libpt.so.1

luca gismo:~$ dlocate libopal.so
libopal-cvs-dev: /usr/lib/libopal.so
libopal-cvs-dev: /usr/lib/libopal.so.2
libopal-cvs: /usr/lib/libopal.so.2.3.2
luca gismo:~$
=====

Thx, bye,
Gismo / Luca

Footnotes: 
[1] it seems quite strangely, however, that the package has been
    removed if it could have been available in non-free
[2] http://www.debian.org/doc/debian-policy/ch-archive.html#s-sections