[Pkg-mozext-maintainers] Bug#559971: Bug#559971: itsalltext: Source package does not contain corresponding source for work

[Ben Finney]

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 <ben at benfinney.id.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-mozext-maintainers/attachments/20091209/127115f4/attachment.pgp>