On Sun, Aug 24, 2014 at 02:46:04AM -0300, Eriberto Mota wrote: > tags 758966 moreinfo > thanks > > > Hi Peter. Hi, and thanks a lot for looking at confget! :) (and at all the other packages that you've sponsored or commented on recently!) > Please, > > 1. d/copyright: I suggest you contract all data about upstream to be > less confused[1]. Example: > > > Files: * > Copyright: 2008-2013 Peter Pentchev <roam@ringlet.net> > License: BSD-2-clause > > Files: makedep.sh t/t1.ini t/t2.ini > Copyright: ? > License: public-domain > This file is hereby placed in the public domain. > > Files: debian/* > Copyright: 2008-2014 Peter Pentchev <roam@ringlet.net> > License: BSD-2-clause > > > Note that I changed the copyright field in second block and added your > email address to other blocks. Please, remove the field 'License' from > header. > > [1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#fields Hmm. Yes, I understand why you personally might prefer coalesced blocks, but IMHO there's no harm in keeping the copyright file an *exact* description of what the upstream source says. It makes things easier for an automated license check tool to make sure that I haven't missed anything; sometimes I use something like: licensecheck --check=. --ignore='/debian/' -r --copyright -m . | sort -k2,20 So, if it's all the same to you, I'd really rather keep it this way - mirroring the full information from the upstream source :) As for the "Copyright: ?" line for the public domain file, I personally think that a "?" or even a "N/A" or similar notation is a bit less descriptive than a piece of text that explicitly mentions "public domain". Yes, it is explicitly mentioned on the next line, in the contents of the "License" field, but IMHO again there's no harm in putting it in the copyright field, too, and for me personally a "?" would be kind of confusing (hey, wait, does this mean that the package maintainer intended to check what the copyright notice should be and then later forgot to check? :)) About my e-mail address in the copyright notices: oof, good catch! :) However, I do not think that this problem should be solved in the Debian package's copyright file - once again, the copyright file should reflect the information in the upstream source, and since I've forgotten to put my e-mail address in the confget upstream source files, I shouldn't claim otherwise in the copyright file :) This will be fixed in confget-1.06, but until then IMHO the copyright file should remain as-is. And about the license in the copyright file header - errrrr, why? From the way I read the "Machine-readable debian/copyright file" standard, there is an optional "License" field in the header, and IMHO it is a very good way to make this information very easily visible - just one look at the header of the copyright file tells you what the program is, where it was downloaded from, who wrote it, and what is the license on most (if not all) of its source files. I've had it in all of my packages ever since it was added to the DEP-5 draft, I've seen it in a couple of others' packages, too, and I still believe that it's a good idea :) > 2. d/rules: remove the second line. Why you used many options in > rules? Well, I happen to very much like the C compiler giving me many, many warnings - both about my code and about others' code that I package for Debian or FreeBSD or whatever :) So I make a point of always building all of my programs (and all third-party programs that I maintain) with the strictest possible set of warning flags, and usually with -Werror, too, so that those are not just warnings, but real errors. One might ask "confget is your program, why don't you put these flags in the upstream source then?"; the answer is that all of these warning flags are GCC-specific - yes, they will work with Clang, but they may not work at all on any other compiler that somebody wants to build confget with. So I cannot unconditionally add them to the upstream Makefile, although I *do* always build with them when I'm working on upstream confget (and stdsyslog, and timelimit, etc). But when I build a Debian package of confget, I know that it will be compiled with GCC (or with a compiler that understands most of GCC's command-line options), so I can afford to use GCC-specific warning flags. When I build my Debian packages, I also have a local addition of "werror" in the DEB_BUILD_OPTIONS environment variable, so the rules file also adds -Werror and things break very quickly if I've messed up :) But yeah, I learned the hard way that releasing a Debian package with "-Werror" by default leads to results that are just a little bit harsher than releasing it without -Werror by default and reading the logs. Ah, yeah, now we come to the last important point - since these are just warnings, what use are they at all? Well, if you're as pedantic as I am, they are actually useful - after any of my packages is uploaded to the Debian archive, I open a tab in my browser, point it to https://buildd.debian.org/status/package.php?p=confget&suite=sid and then check it repeatedly in the next couple of days until all the buildds have actually finished - *and* I read all the build logs to check for warnings that were not present on my machine, but appeared there. Yep, it is a bit boring sometimes :) But it works - and it did help me notice such architecture-specific warnings at least twice in the past. So, once again, if it's all the same to you, I would much prefer to keep both the unconditionally-added warning flags and the conditionally-added -Werror flag. All of the C/C++ packages that I maintain have such stanzas in their rules files and so far nobody has objected. Once again, thanks for your review - and, uhm, thanks a lot for reading this far! :) So... now that I've explained (at LENGTH!) my reasons for doing things in this way... is it okay with you? G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@FreeBSD.org p.penchev@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Attachment:
signature.asc
Description: Digital signature