On 08-Dec-2009, Jan Luebbe wrote: > On Tue, 2009-12-08 at 12:17 +1100, Ben Finney wrote: > > The source package for ‘itsalltext’ is not the corresponding > > source for the work. Instead, it is a bundling of the binary > > ‘*.jar’ libraries. > > The jar 'libraries' are just zip archives of the source code.
Not quite; see below. > > The GPLv3 defines the “corresponding source” as: > > > > The "Corresponding Source" for a work in object code form > > means all the source code needed to generate, install, and > > (for an executable work) run the object code and to modify the > > work, including scripts to control those activities. > > The work is not shipped in 'object code' as i understand it, just > compressed original .js and .xul files. The jar files have been > obtained by extracting upstream's .xpi file. That's still not the “corresponding source”. As can be seen, it doesn't include the source in the form the upstream developers use to build the package. It is missing at least the ‘Makefile’, which in turn requires the working tree to be laid out as the upstream VCS repository is laid out. > > So, fixing this bug involves changing the source package to > > consist of the corresponding source for the work plus the Debian > > packaging, all licensed appropriately. > > For the next upstream version, i will change it to the recommended > pkg-mozext style where the the jars are extracted. The ‘foo.xpi’ is not the complete source though, even when extracted. Since the upstream source is kept under VCS in a Git repository, would it not be better to base the source package on an export from a specific tag from that repository? Even better, of course, would be to encourage upstream to make source tarball releases of each version, and use those as the pristine source. > I've had not seen this git repo before and have now compared the > source files in my package to those in git. They seem to be > identical. Great, that makes it clearer that the VCS working tree contents are the pristine source (or convince upstream to make tarball releases each version). > What do you think we would gain by using the git repo as upstream? The recipient of the Debian source package should be in a position to modify the source and build new binary packages, as much like the upstream developers as feasible. The Debian policy § 4.14. strongly implies that ‘dpkg-source -x foo.dsc’ should result in the complete source of the package ready for editing and building. This seems simplest if the source package is based directly on the source the upstream developer is using (e.g. from their VCS or a tarball export), not from a reverse-engineered binary package with no build script support. -- \ “Always do right. This will gratify some people, and astonish | `\ the rest.” —Mark Twain | _o__) | Ben Finney <b...@benfinney.id.au>
signature.asc
Description: Digital signature
