Hi Mike,
On Tue, Sep 15, 2009 at 08:38:58AM +0200, Mike Hommey wrote:
> On Mon, Sep 14, 2009 at 09:18:00PM -0700, Steve Langasek wrote:
> > On Mon, Sep 14, 2009 at 08:40:34AM +0900, Charles Plessy wrote:
> > > Having a mantadory Files: field was strongly opposed on debian-devel
> > AFAIK the opposition was from people who opposed the machine-readable
> > copyright format altogether, not from people who are planning to use the
> > format and are looking to improve it. The DEP should not cater to the whims
> > of people who aren't going to use it anyway.
> On the other hand, the DEP should make it possible for more people to
> use it, not make it impossible. Basically, having the Files field
> mandatory means no big package will ever use it. Ask Gustavo Noronha how
> fun it is, and how long it takes to update the debian/copyright file for
> webkit at each new upstream release, which is only medium sized. Not
> only is it not fun and time sucking, but it is also very error-prone.
> I'm pretty sure I involuntary introduced errors when I was still
> maintaining that file, which are probably still out there.
This particular subthread is about whether or not the 'Files: *' field
should be mandatory in the first ("default") stanza. Isn't it obvious that,
*if* you're using multiple stanzas, the *additional* stanzas need Files:
fields? Else, why would you have multiple stanzas?
> And while software like fossology could help a lot, they still leave a
> massive amount of manual work to be done.
I think much of the criticism of DEP5 is due to a misperception that the
machine-readable format requires maintainers to provide more detail than
they are required to provide today. There's no reason that this should be
the case. If you have a package with 800 source files, 30 copyright
holders, and three different (but compatible) licenses, for instance, I
don't see anything wrong with declaring your copyright file like this:
Files: *
Copyright: 1999-2005 Person One, 2003-2007 Person Two, [...]
License: LGPL-2+ and GPL-2+ and BSD-with-cheese
License: LGPL-2+
<license text>
License: GPL-2+
<license text>
License: BSD-with-cheese
<license text>
... unless, that is, you find that listing the licenses in a lump applying
to the package as a whole is inappropriate, perhaps because it's misleading.
But if you hold that opinion (as, judging by many debian/copyright files
I've looked at, a fair number of maintainers do), you have to do more work
to document the copyright/license *anyway*, and use of the machine-readable
structure doesn't significantly impact the work one way or the other; it
just provides a structure you can plug the data into.
Starting to dogfood the DEP on unixodbc, for instance, I went with the
following:
Files: *
Copyright: 1999-2005 Nick Gorham <nick@easysoft.com>,
Peter Harvey <pharvey@codebydesign.com>, et al.
License: LGPL-2+
Files: exe/*, odbctest/*
Copyright: 1999-2005 Nick Gorham <nick@easysoft.com>,
Peter Harvey <pharvey@codebydesign.com>, et al.
License: GPL-2+
Files: DRVConfig/esoob/esoobS.c
Copyright: 1999 Easysoft Ltd.
License: LGPL-2+
Files: Drivers/nn/*
Copyright: 1995, 1996 Ke Jin <kejin@visigenic.com>
License: GPL-2+
License: LGPL-2+
<blah>
License: GPL-2+
<blah>
But if I wanted less detail I could just as easily have compressed this to
two File stanzas (one for all GPL-licensed code, one for all LGPL-licensed
code), or even one with just "License: LGPL-2+ and GPL-2+". (But not, I
would note, "License: GPL-2+" even though the LGPL would allow this, because
this is a library that we have to link a variety of other code against so
the LGPL permissions are relevant to Debian and should be explicit.)
And as and when tools start to appear that can generate debian/copyright in
this format, we can probably tweak them to optionally spit out the stanzas
in each of these styles.
> Let's also add something I pointed out last time: the debian/copyright
> file is mostly relevant for *binary* packages, yet, we fill copyright
> for *source* files and provide no information for *binary* files at all,
> while having a machine-parseable copyright has, IMHO, a more interesting
> benefit for binaries than it has for sources (especially sources of big
> packages). But I admit gathering these informations together would mean
> even more work than what copyright files require already.
I agree; I would also prefer being able to track copyright on a
per-binary-package basis. I think that's out of scope for DEP5, however.
If I were trying to solve this on my own packages, I would probably go with
separate debian/<pkg>.copyright files for each binary which I update by
hand, plus logic to regenerate debian/copyright in the clean target. Hmm,
but a tool that can look at the make rules for a given binary output,
identify its dependencies, gather copyright information for those files and
output it in a machine-readable copyright format would be interesting to
see. :)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature