Wouter Verhelst <w...@uter.be> writes: > [W]hile I agree that this is a problem for things like precompiled > Windows binaries, I'm not so sure when it regards convenience copies > of minified javascript libraries. After all, there are many other > packages whose upstream source ships with convenience copies of other > code, and we don't consider those to be problems.
That is apparently conflating two distinct issues: A third-party work in *source* form in the Debian upstream source is not in itself a problem: if it is known to be free software, we can confidently ship it in the Debian source package as a work in source form. A work in *non-source* form in the Debian source package is more likely to be a problem. If we cannot verify the corresponding source is also distributed in Debian, we can't state with confidence that we have it; without corresponding source for that work, the package will violate the DFSG. The issue being discussed is not convenience copies of code (problematic in the binary package, but AFAIK neutral in the source package). The issue rather is non-source works in Debian source packages. We now have the ftpmaster team's clarification that the Debian source package is part of Debian; and that such works in non-source form, without corresponding source known to be in Debian, are not acceptable in the Debian source package. > If a package will work equally well when using the Debian-packaged > version of a javascript library rather than using the shipped > convenience copy of the said library (as proven by using a symlink and > a dependency to the relevant file and package rather than shipping the > convenience copy in the binary package) The Debian source package also needs to be free software. If a non-source work can't be demonstrated to have its source also in Debian, then distributing that work in the Debian source package threatens breach of the Social Contract to recipients of Debian. > then the source requirements for all relevant code is satisfied; it's > just that they're done so by another source package. Sure. Shipping the source for a work in another Debian source package is fine; the problem is for the package maintainer to assert that *is* the corresponding source for a particular work. We should not, IMO, accept such an assertion without an independently verifiable guarantee that can be automated for each release of the source package. I can see two ways for Debian package maintainers to make that guarantee with confidence: * Automatically perform a hash check of the non-source work against a specified other non-source work in Debian, for which we have a reliable guarantee the corresponding source *is* in Debian; and automatically reject any release of the package if the hash does not match. This pushes the question of how to make the guarantee of corresponding source to yet another package. Such verification also doesn't AFAIK have any systematic automated support at present. It also sounds to me like more work and error-prone complexity than the second option: * Discard the non-source work when re-packing the upstream source, to ensure it does not appear in the Debian source package. If the non-source form is needed for the binary package, re-generate it at build time from that work's corresponding source. Distributing the non-source work in the Debian source package, without automatic verification each release that its corresponding source is in Debian, leaves us wide open to the divergence of that work from what we hope is the corresponding source, and thereby breaking our promises. -- \ “I do not believe in forgiveness as it is preached by the | `\ church. We do not need the forgiveness of God, but of each | _o__) other and of ourselves.” —Robert G. Ingersoll | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85mweudpkj....@benfinney.id.au
