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



Ciao Luca,

On Thu, Aug 30, 2007 at 01:49:33PM +0200, Luca Capello wrote:
> Ciao Kilian!
> 
> On Thu, 30 Aug 2007 08:08:30 +0200, Kilian Krause wrote:
> > On Wed, Aug 29, 2007 at 11:06:17PM +0200, Luca Capello wrote:
> [...]
> >>>> dpkg-shlibdeps: warning: could not find any packages for libopal.so.2.3
> [...]
> >> 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.
> 
> FWIW, I'm trying to debug it myself, too.

Good. If you find something, just point me to it. Especially I don't
understand why this doesn't happen with the opal in Debian. IF you have
some time on your hands, try diffing and maybe tracing the debhelper
moudles to track this down. It kinda bothers me, because the behavious
is plain *wrong* as is. ;)


> >> 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.
> 
> Mmm, I'd say that we should stick with Debian official packages as
> much as we can.  Since etch still have libavcodec0d while lenny and
> sid libavcodec1d [1], wouldn't "libavcodec0d | libavcodec1d" do the
> trick?

Sounds good enough. 
Sarge: - (would need backporting)
Etch: libavcodec0d
Lenny/Sid: libavcodec1d
Dapper: - (would need backporting)
Edgy: libavcodec0d
Feisty: libavcodec0d
Gutsy: libavcodec1d

Thus, added as you proposed.


> >> 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?
> [...]
> > 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.
> 
> I guessed that and that's way I specifically asked why libx264 isn't
> fully dynamically loaded (as libavcodec).

Maybe Matthias can provide a "fix" to this. Then the Depends will also
move to Suggests.


> > The *-cvs variant is not intended for Debian. It's an external
> > repository.
> 
> I'm aware of that, but since you're also the maintainer for the
> official Debian version, I guess you base your work on the *-cvs
> variant.  Anyway, nevermind.

Yes, they're kept as "identical as possible" for exactly that reason.
Yet I have some limits in Debian that I "extended" for the -cvs snaps to
make some developers a bit more happy. ;)


> > 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).
> 
> I wasn't aware of iLBC, thank you for the info.

The whole of Debian isn't shipping iLBC - i.e. you'll also not find it
in asterisk. And well, maybe I will split out the ilbc plugin to make it
"pluginable" to a regular Debian install. (well, when I have the time to
do that, or so.)

-- 
Best regards,
Kilian

Attachment: signature.asc
Description: Digital signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]