reasons for split of libavcodec54 and libavcodec-extra-54, missing codecs and a metapackage.

[Fabian Greffrath]

[cleaning up CC: list]

Am Montag, den 17.11.2014, 19:14 -0500 schrieb Reinhard Tartler: 
> I would probably lean towards option 1, but don't feel strongly about
> any of the presented options. Option 2 was a necessity to make the
> "libav-extra" source package hack work. I think a shlibs.local file is
> most explicit, as it allows to document the intention clearly in place
> and avoid special-case dependencies in the debian/control files (which
> is why I'd lean towards that option).

The problem I see with shlibs.local files is that they are another
source of noise in the debian/ directory and might get overlooked
whenever one of the SONAMEs changes. Alternatively, the shlibs.local
file could get dynamically created in debian/rules, adding more noise
there in turn.

What I like about the explicit dependencies in debian/control is that
they have to get revised anyway whenever a SONAME changes. For example,
we already have libavutil-dev "Depends: libavutil54 (=
${binary:Version})" and I would simply add that very same line to the
Depends fields of libavcodec56 and libavformat56.

> Thanks for the research, that's indeed helpful.

Indeed very helpful, thank you Andreas!

> What can we do about this in Debian? Well, I don't really feel like
> maintaining a list of packages that are GPLv2 only in debian/control.
> Instead, I'd very much prefer those packages to install a shlibs.local
> file that avoids the alternative dependency on the -extra- flavor.

I also think we are not required any more actions to avoid simultaneous
installation of license-incompatible packages, we cannot prevent users
from shooting in their own foot. I think the alternative dependency
prefering the GPL2 variant and our explicit stating of the license
implications of the -extra package in both the package description and
the debian/copyright file should suffice.

I consider this similar to the case in which an alternative dependency
on a package in non-free is still suitable for main: installing the
non-free package might result in whatever license violations, but it is
an explicit choice of the user (on his own system, in his own
responsibility) and the default choice is still safe.

> We used to ship x264 in the -extra- package, which is very popular. I
> suppose that many users are very interested in the AAC encoders,
> because the native encore inside libavcodec is of rather poor quality.
> Also, AMR seems also be rather popular if you own a device that
> requires that codec. I would say that effort is very much worth it!

The AAC and AMR* codec in the -extra packages are definitely "nice to
have". From my point of view, our discussion here shows that the split
between the regular and the -extra libavcodec package is still
necessary: as has been pointed out above, we cannot ship the codecs in
the main package and the alternative would mean dropping the extra
package, which is also out of question.

Thanks for your discussion!

- Fabian