Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Tanguy Ortolo writes ("Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)"):
> 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?
The current approach of the project in these cases seems to be that
the right thing to do is to rebuild the source package so that the
non-free pieces are removed.
Personally I think this is a complete waste of everyone's time;
particularly, rebuilding upstream source archives is troublesome and
doesn't really benefit anyone.
I'd much rather you could just write in your .dsc a set of glob
patterns for files to remove, somehow, which dpkg-source would remove
when you unpacked it (unless you told it not to). That would prevent
the non-free files from being accidentally used during the build
process or shipped (eg when upstream Makefiles change), but would save
a lot of work. It would also mean that the upstream tarball in our
archive would be the real upstream tarball.
I can see that there might be the objection that we were then
distrubuting non-free stuff from our main archive section but given
that our archive is almost entirely used by people using our tools,
this is a small price worth paying for not obstructing our work on the
free parts of the package. Obviously if the non-free parts are
significant in size this doesn't apply.
The benefit would be that we would no longer have to rebuild upstream
source packages where upstream has helpfully included files such as
RFCs (which we usually consider non-free) or other non-free stuff.
Upstreams normally regard it as a convenience for people, to provide
apocrypha etc. in their tarballs, and to be honest they're probably
right. We are making a rod for our own back by our current practice
of insisting on repackaging their tarballs.
(I'm assuming that the non-recompilable binary is distributable. If
it isn't then it can't be in our archive at all of course.)
> 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.
No. There is no sensible way to do this. The problem is inherent:
the binary packages in main have to be rebuildable using the source
package (and supporting binary packages eg compilers) in main.
If you have this situation you have to have two separate source
packages; one in main which builds only the free parts, and one in
non-free which builds only the non-free parts.
Ian.
Reply to: