On 20.09.2014 09:57, Tobias Frost wrote: [...] >> First of all I'd like to suggest that you start with the ufoai source >> package first because it contains the ufoai_copyright.py script and >> other information that are useful to understand the packaging of >> UFO:AI's data packages. > > My reasoning is, that because of every data package has its own > orig.tar, they need to be crafted in a way to so that they will > be -- individually looked at -- reach Debian quality requirements. I still don't see why the current copyright file does not meet Debian's quality requirements. Instead of one huge 900 MB -data package, the game data was simply split into three different source packages. This makes it much easier to fix bugs without having to upload all data files every time. I would like to stress: The source packages are not independent of each other, they belong together. It is due to mere technical reasons that the -data was split. In my opinion we are in full compliance with Debian's Policy because - we state in d/copyright that the game data was split due to technical reasons - we use a reproducible and convenient way to determine all copyright information. - the copyright file is machine-readable and every file in each source package is covered by an license paragraph in debian/copyright. Thus the whole copyright file is accurate. [...] > Admitting, upstream is exemplary in case of tracking of its licenses > (also with the scope for Debian!), and it really helps to automate this > to get a skeleton dep5 file. Indeed. UFO:AI is an exemplary and excellent free software game and its developers care a lot about tracking licenses. > However -- as with the output of licensecheck of the devscripts -- the > output needs to be checked and compared to *every* files in the source. Right. This is already achieved. Which license information are incorrect? > The LICENSE file may (and have) also errors: For example there are files > in this files with no copyright holder attributed. Or, there are URLs > attributed as copyright owners. How does the script handle this? In the > end this leads to wrongly attributed files that will either go unnoticed > (so Debian is violating copyright law) or lead to an FTP Master reject. First of all the whole game is licensed under GPL-2+ and is copyright The UFO:AI team. In addition the LICENSES file contains all information about individual game data licenses that diverge from this general assumption. One line in LICENSES looks like that: filename | license | author | source base/maps/africa/af_empty6a.map | GNU General Public License 2.0 or later | Holger 'ShipIt' Gellrich | base/maps/africa/af_empty6.map The script splits all fields by the | delimiter and maps all filenames to their corresponding licenses and copyright holders. If there is no one mentioned under author one may assume that this is always a work by the UFO:AI team. > > To make it clear: I require an 100% accurate d/copyright and this is one > of the few points that are not subject to negotiations. Absolutely. Could you elaborate on where a file is not accurately addressed by copyright format 1.0? [...] >> I believe we shouldn't make the process of creating debian/copyright >> even more painful and I think that a reference to >> /usr/share/common-licenses is more than enough for the most widely used >> free software license. > > I disagree. As said above, d/copyright is important. Yes, it is tedious > to create it the first time and there are more exciting things to do, > but it is a necessity to be done and to do it right. Absolutely agreed. But can you point me to examples where the short reference to /usr/share/common-licenses was deemed not appropriate by the FTP team? > The policy means you should not quote the verbatim license, but it is > common practice to quote the first 3 paragraphs. No, that's not true. A lot of maintainers write standalone paragraphs for common licenses exactly as I do. > Otherwise we'll introduce fuzziness. Consider License GPL-2+ > You refer to the GPL-2 file, which makes it non-obvious that you have > the "or later" option in place. For the causal user, its not > self-explaining what the "+" means. Copyright format 1.0 clearly defines short names and keywords. GPL-2 and GPL-2+ are well defined and unambiguous. https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ It is common practice and knowledge that GPL-2 refers to the GNU General Public license 2 and GPL-2+ refers to the same license but includes the "or later" clause. > Please add the few lines, I consider it not enough to just have the > reference. Ok, that's fine. I completely understand that it is your prerogative as a developer to determine what you consider suitable for an upload. However I have touched more than 100 source packages already and I am sure that this is not what Policy demands and merely an arbitrary requirement. Even the rules for copyright format 1.0 state for the License field: "Otherwise, this field should either include the full text of the license(s) or include a pointer to the license file under /usr/share/common-licenses." A pointer is really enough. [...] >> d/watch just checks for new releases. It is far more convenient to work >> with the upstream Git repository hence I have created get-orig-source >> targets in src:ufoai. > > As said in the beginning, I disagree. Each package needs to induvidually > fulfill the quality requirments. > > If the watchfile does not retrieve the source, you need to have a > get-orig-source in d/rules and document who to get source for that > package in README.Source. But there is a README.source file in ufoai-music and it points to src:ufoai where you can find all get-orig-source targets to retrieve the original sources? Why is this not sufficient? > You can recommend there to go ufoai and > execute get-orig-source there to avoid double downloads, but I expect > that this will be possible also without downloading another source > package. Sure I could duplicate the same code for every source package but what would we gain? Quality? Reduction of maintenance work? > (BTW, As you are repacking, so you should add the suffix +repack to the > upstream version; this makes clear that you won't find the tarball > upstream) Yes, but strictly spoken we don't repack the sources. We just use the Git repository directly. Therefore I think +repack would be misleading. Markus
Attachment:
signature.asc
Description: OpenPGP digital signature