[SCM] FFmpeg packaging branch, master, updated. upstream/0.svn20090119-38-g4098a63

[Reinhard Tartler]

Fabian Greffrath <greffrath at leat.rub.de> writes:

> Dear Reinhard,
>
> Reinhard Tartler schrieb:
>> Loïc, I hope you don't feel yourself passed over, but considering that
>> the source package is used in more places than just debian/main, I
>> really feel that having a shlibs.local like this is the best way to
>> proceed. If you feel that this is a bad idea, please elaborate, I'm
>> happy to discuss this and this change can be reverted at any time.
>
> sorry, but I am not pleased with the way this was implemented:
>
> 1) We need two separate shlibs.local files, one for ffmpeg-debian and
> one for ffmpeg with the *-unstripped* libraries (as we have two separate
> debian/control for these two cases). The way it is now, it still allows
> to mix up stripped and unstripped libraries and we have not yet tested
> if this works (I suppose it doesn't).

Because of the way stripping is currently implemented, mixing the
stripped and unstripped variants is no problem. I've tested that on my
machine myself. That's the main reason why I've weakened the
dependencies.

In fact, we could probably just create an replacement libavcodec, and
take the other libraries from the 'ffmpeg-debian' package. When
discussing the whole approach, we agreed (at least I think that we did)
to generate the 'other' ffmpeg libraries as well, so that in case we
update the 'ffmpeg-debian' package, users who have selfcompiled the
stripped variants still have a version of the other libav* package that
match to their version of avcodec.

That's why I'd say that we don't strictly need 2 seperate shlibs.local
files. But generating them from debian/rules is technically no problem
either.

>
> 2) You have losen the dependencies to ">=". Again, the striking part of
> my proposal was the strict "=" dependency. As soon as Marillat (or
> whoever) releases a snapshot newer than ours, the benefit of the
> shlibs.local file will be void, if it introduces only the relaxed
> dependencies. Newer snapshot will always satisfy (>=
> ${source:Upstream-Version}) and then we'll again end up with the mix-up
> that we initially wanted to avoid.

Ideally he'll ship the unstripped version of ffmpeg in his repositories,
and we don't have to think about this again.

> The general idea is: Packages that link against our ffmpeg libraries are
> free to choose between the stripped and the unstripped variants of the
> libraries. But as soon as the user has decided for one of both sets, I
> shouldn't be possible to mix up the two variants -- not to mention
> unofficial/unsupported third party variants.

as indicated above, mixing is really no problem.

> This is only possible if we make sure that higher-level libraries
> depend on lower-level libraries from exactly the same
> *build*. Dependencies beginning with ">=" may be satisfied by random
> packages.

not random, but packages with a higher version number.

> I strongly believe we should go this way, because:
> - all library packages are arch:any and will therefore hit mirrors
> simultaniously.

you mean for a given architecture? right.

> - we may introduce ABI/API changes via patches in an '-2' upload.

indeed, but in that case we need to touch the dependencies manually
anyways.

The problem I see with the overly strict dependencies is that as soon as
we update ffmpeg-debian, there is a latency until the users have
self-compiled their own 'ffmpeg' packages. Let us assume there was a
security patch in libavformat. in that case the user wants to install
the latest libavformat ASAP even if he has the unstripped variant of
avcodec. [1]. As outlined above, this is currently really no problem, as
strip.sh touches only files in libavcodec/*

I do understand your position to play safe and require the exact build.
However I think this is not strictly necessary and the current
implementation is sufficent. I also think that escpecially users of
stable versions of debian and ubuntu will benefit from the weaker
variants, less users of sid. I'd like to ask you to rethink the
issue. if you still believe that we should go with the stricted
dependencies, I'll revert the last commits and implement the stricter
version.

[1] of course if there is a security patch in libavcodec, then there is
nothing we can do about that. but issues in avformat are not that
unlikely, given the security history...

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4