Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> 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.
Is it? My understanding was that as long as the upstream tarball is
legaly distributable and the unneeded/unwanted parts in it aren't too
big then the pristine tarball should be used as is.
The clean target should then remove the extraneous files so they are not
(accidentally) used during build, so that all binaries are build from
fully DFSG free sources.
> 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.)
Which is the case for flash, isn't 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.
>
> 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.
Actually you can have a source in main that builds binary packages for
main and contrib. There are (or were) a few examples in Debian. But as
you say the source in main must be buildable with just main.
The case of non-recompilable binaries just doesn't fall into this
category. The non-recompilable binary will never be DFSG free and has to
go to non-free, not contrib, imho. Or it has to Build-Depend on
something outside main to make the binaries recompilable and then the
source can't be in main as it becomes unbuildable with just main.
MfG
Goswin
Reply to: