[SCM] FFmpeg packaging branch, master, updated. debian/0.5+svn20090609-1-22-g6b646aa

[Andres Mejia]

On Tuesday 14 July 2009 05:56:24 Reinhard Tartler wrote:
> Fabian Greffrath <greffrath at leat.rub.de> writes:
> > Reinhard Tartler schrieb:
> >> Is it really necessary to start a commit war here?
> >
> > o_O Indeed!
> >
> > Non-PIC in shared libraries is not a policy exception [BTW: Who grants a
> > policy exception? You?!],
>
> I'm not even convinced that this is a policy violation at all. The fact
> that lintian declares this as ERROR is understandable, but the
> classification is in the case of FFmpeg just wrong. Let's read again the
> relevant policy section
>
> ,----[10.2 Libraries]
>
> | If the package is architecture: any, then the shared library
> | compilation and linking flags must have -fPIC, or the package shall
> | not build on some of the supported architectures[60]. Any exception to
> | this rule must be discussed on the mailing list
> | debian-devel at lists.debian.org, and a rough consensus obtained. The
> | reasons for not compiling with -fPIC flag must be recorded in the file
> | README.Debian, and care must be taken to either restrict the
> | architecture or arrange for -fPIC to be used on architectures where it
> | is required.[61]
>
> `----
>
> I don't really see the need of discussing this on debian-devel, and in
> fact, I am sure that this has been discussed to death there a long time
> before we all started working on the package.
>
> Okay, strictly speaking, not giving the rationale about this in
> README.Debian can be understand as policy violation. But AFAIUI, this is
> not what lintian complains about.
>
> And now footnotes 60 and 61:
>
> ,----
>
> | 60
> |
> | If you are using GCC, -fPIC produces code with relocatable position
> | independent code, which is required for most architectures to create a
> | shared library, with i386 and perhaps some others where non position
> | independent code is permitted in a shared library.
> |
> | Position independent code may have a performance penalty, especially
> | on i386. However, in most cases the speed penalty must be measured
> | against the memory wasted on the few architectures where non position
> | independent code is even possible.
> |
> | 61
> |
> | Some of the reasons why this might be required is if the library
> | contains hand crafted assembly code that is not relocatable, the speed
> | penalty is excessive for compute intensive libs, and similar reasons.
>
> `----
>
> These consideration exactly apply to the ffmpeg package. So, what is
> again the point here? Just Making lintian happy?!
>
> > it is a bug, even on i386.
>
> I'm not even convinced that this is a bug. The reason is performance,
> and libavcodec is about implementing *fast* encoders and decoders.
>
> > The only reason why we don't touch it is that we don't want to divert
> > from upstream and leave it up to them to fix it. Upstream is very
> > sensitive about Debian modifying their code, you know?
>
> They have a very strict review process, that's true. And the project
> itself profits very much because of it.
>
> I can understand why people want a PIC version of ffmpeg: some modern
> linux security features rely on that. Still, I think the performance
> concern is of greater importance here than supporting non-default
> security features in debian. We can rediscuss this when SELinux or
> something gets enabled by default in debian.
>
>
> So, what about this lintian warning? I currently feel that the lintian
> check should be "fixed" to query for some special string in
> README.Debian that indicates this situation and just not emit this
> error. Currently, that check is implemented in the lintian source in
> checks/shared-libs, around line 100:
>
> ,----
>
> |         # Now that we're sure this is really a shared library, report on
> |         # non-PIC problems.
> |         if ($cur_file eq $real_file and
> | $info->objdump_info->{$cur_file}->{TEXTREL}) { tag
> | "shlib-with-non-pic-code", "$cur_file";
> |         }
>
> `----
>
> That check could perhaps check for some magic in README.Debian.
>
> This effectivly implements a lintian override in README.Debian. Which
> makes more sense to me here.

Ok. Well I'm sorry to even start all this. I've now found that mail where Fabian 
asked if I had any objections, in which case I did and still do (sorry Fabian).

In regards to the lintian overrides for the non-pic shared libs error messages, 
it's not really a matter of silencing lintian. I had the general idea that the 
override would serve as an indication that we know about the error message, 
we're giving an explanation on why we're overriding it (because it's not an 
error, etc.), and we're avoiding any bug reports or complaints by others about 
the errors.

-- 
Regards,
Andres