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