[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)


I know that there is a recent thread that talked about the status of
non-recompilable binaries in packages, with the common particular case
is Flash applets.

As I understood it, the overall conclusion was: even if their licence is
DFSG-free, according to the policy section 2.2, packages containing such
binaries cannot go to main and, if distributed, must go to contrib. I
agree with that, but I think the reality is more complex, as software
can be built of several, partly independant bricks.

Indeed, as a package can be a source package or a binary package, I
wonder how this applies. First of all, as the control file allows to set
the section both for the source package and for each binary package, can
a source package be in a different area than one of the binary packages
it generates?

Let us say an upstream tarball contains such a non-recompilable binary
as a minor component that can be stripped and maybe distributed by other
means. The debian/rules will not compile it (it cannot), but if it does
not even include it in the generated binary package, would such a
package (both source and binary) “not require a package outside of main
for compilation or execution”? In other words, to be in main, does the
maintainer have to strip the problematic file from the binary package,
or does he have to repack the original tarball stripping it?

Same case, but with two binary packages generated, one with the main
content, the other one with the problematic files appart: can the source
file be in main? That case does not apply if all the packages associated
to a single orig tarball must be in the same area.

Tanguy Ortolo

Attachment: signature.asc
Description: Digital signature

Reply to: