[SCM] FFmpeg packaging branch, master, updated. debian/0.5+svn20090706-1-6-gf90dd6a

[Andres Mejia]

On Tuesday 08 September 2009 04:01:11 Fabian Greffrath wrote:
> Andres Mejia schrieb:
> > If we wanted to encourage people to use debimedia, than we shouldn't even
> > mention that they can just comment out that line. Also, not to insult
> > anyone,
> 
> Generally I agree with you. However, I think ffmpeg is an exception,
> because here the code to build extra features *is already there*.
> There is no need to install additional packages that are not part of
> Debian to enable this specific set of encoders. We have artificially
> disabled them and it is really only necessary to comment out this one
> line, so I think we should still offer this (unsupported) alternative.
> 
> > but if we wanted to encourage people to use debimedia, we should do a
> > better job of keeping debimedia up to date.
> 
> debimedia is still work in progress and is has not even been announced
> yet - at least not outside the pkg-multimedia list. At the moment we
> are tracking unstable, whích is a moving target naturally, and we are
> missing manpower (i.e. Reinhard).
> 
> > Also, I don't see how this is more intuitive. What I see is that anyone
> > tracking the ffmpeg packaging will have to keep commenting out that line
> > every time they want to build the restricted encoders. It would be much
> > easier if we would just make use of DEB_BUILD_OPTIONS for this kind of
> > case, especially since it's frequently used.
> 
> Anyone who wants to activate the missing encoders in ffmpeg will have
> to rebuild the package anyway - each time a new version has been uploaded.
> 
> I see no *big* difference between running "DEB_BUILD_OPTIONS=foobar
> dpkg-buildpackage" and editing a line in debian/confflags. but what I
> find more intuitive is that in order to introduce a *change* in the
> library packages (i.e. activation of restricted encoders) during
> rebuild, you actually have to apply a *change* to the packaging.

The difference I see is instead of doing "DEB_BUILD_OPTIONS=blah dpkg-
buildpackage ...", someone may have to do "sed blah blah && dpkg-buildpackage 
...". I certainly do not think resorting to sed or manually editing 
debian/confflags is more intuitive than simply running a single command.

Furthermore, your argument can be taken the other way.
"in order to introduce a *change* in the library packages (i.e. activation of 
restricted encoders) during rebuild, you actually have to apply a *change* in 
the *options used to build the packages*."

> > Also, I'm not sure what you mean by documentation, but the change would
> > be set in the build logs, when it would (or use to) show whether or not
> > 'internalencoders' was set. It would also be seen if encoders were being
> > disabled through the ffmpeg build system and it can be checked again with
> > 'ffmpeg -formats'.
> 
> People who have to rebuild ffmpeg packages at home usually don't have
> a build log afterwards.

Unless they use debuild/sbuild/pbuilder.

> To make it short: I want to avoid that ffmpeg packages that have been
> rebuilt to enable the restricted ancoders look *exactly* the same as
> the official Debian packages - including the diff.gz. It shouldn't be
> possible to activate the codecs "by accident" and then forget about
> it; instead it should be a decision made by the user, it should need
> modification and saving of a file and should in the end also get
> documented in the resulting diff.gz.

Assigning anything to "DEB_BUILD_OPTIONS" is a decision that a user has to make. 
Also, it is just as easy to forget to uncomment that line and leave it in the 
packaging.

Furthermore, at least there's some advantage to using the options approach. 
Packages built with the restricted encoders and accidentally uploaded to the 
archive will not cause all other archs to be built with restricted encoders. 
This will not be the case if the change is left in the diff.gz, where all archs 
will have the restricted encoders enabled.

> Fabian
> 

-- 
Regards,
Andres