Enable faad support in ffmpeg/experimental

[Reinhard Tartler]

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

>> It doesn't make too much sense to me, since
>> it would work then inside the top level of the upstream source, creating
>> a subdirectory with another copy of the upstream source. 
>
> It's a temporary directory that will be deleted afterwards anyway.
>
> For your understanding, the script is supposed to be run inside your
> local SVN tree *before* you even have the source code (note that it
> saves the tarball in ../tarballs). I.e. you prepare a new package by
> first creating a new changelog entry (introducing a new source version)
> and secondly running the get-orig-source rule. Not till then you have
> your working source tarball.

Here you assume that it makes sense to checkout the debian directory
without having the upstream source. I do not agree here, since I always
checkout the debian directory inside an ffmpeg source tree. Moreover I
don't use svn-buildpackage.

Hm. I need to see how to improve the get-orig-source rule.

>> the newly created subdirectory ffmpeg-free-0.svn20080206 does not
>> contain a debian/ directory yet, so it cannot run debian/strip.sh here.
>
> Argh, it's supposed to be 'sh ../debian/strip.dh', I guess.
>
>> Ideally the script would create a temporary directory in /tmp, prepare
>> the source, tar it in a tarball and copies the tarball either on stdout
>> or in the current working directory.
>
> IMHO it doesn't matter where the temporary directory is created.

In principle it indeed doesn't matter too much. however, running in /tmp
has advantages:

 - less risk that some accident happens with the source
 - the source directory can be ro (granted, a weak reason, but a good
   habit, IME)

>> I do hope that not, however I'm not sure. I'm still looking for a
>> reliable for checking this.
>
> Hm, we could compare which symbols are provided by the libraries before
> and after running debian/strip.sh (and then compiling...).

This won't buy us much, since strip.sh is modifying types, which don't
alter then names of the symbols. This means that we need to carefully
review the exported types here. And I'm still looking for a way how to
automate this somewhat :(

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