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

[Reinhard Tartler]

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.


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