Re: Non-source Javascript files in upstream source
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
Reply to: