Hello, 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