The package has now been uploaded, but Julian gives useful feedback which I'll respond to here.
Julian Andres Klode <[email protected]> writes: > First of all, because you are not compiling anything, you don't have > to build-depend on python-all-dev. In fact, you can simply > build-depend on python [it's just copying the file to a directory]. Don't I need to depend on ‘python-all’? Since the package is to be installed to *all* Python versions in Debian, not just the latest one. Also, should the build dependency on Python be ‘Build-Depends’ or ‘Build-Depends-Indep’? > And since you are using dh7, you can simplify your debian/rules even > more. And using python-support instead of python-central would also > reduce the complexity. Thanks. I plan to migrate my packages to ‘python-support’, once the improved 0.90 series enters ‘testing’. > And you should also install RELEASE-NOTES as changelog.gz, as specified > in Policy 12.7: I considered that, but the file is quite out of date (at least four subsequent releases without any entry in the file). > If the upstream changelog files do not already conform to this naming > convention, then this may be achieved either by renaming the files, or by > adding a symbolic link, at the maintainer's discretion." I agree that for this package, the content of ‘RELEASE-NOTES’ is pretty much that of a changelog. In general, though, what's the guideline for how non-changelog the file contents can be before it's not really appropriate to use it as the upstream changelog? Many upstream packages contain a “notes to the user about recent releases” file, which would be more appropriate as ‘NEWS’ in a Debian package. > BTW, have you considered to use the original license for your > packaging as well? For the packaging work which isn't modifying the upstream work, I intend to continue using GNU GPLv2+. > Because the time you add a patch to your package, the combination of > both is GPL licensed as well. Using the same license as the upstream > helps people to detect the correct license of the resulting work in > an easier manner (and upstream maybe likes you more if you use the > same license). This is the first package where I've used ‘debian/patches/’; I hadn't thought about this issue. Thank you, you've convinced me that ‘debian/patches/*’ will be under the same license terms as the upstream work in any future release. > Last but not least, I prefer to sponsor packages using a single > revision for every upload made to Debian. Even if the ‘foo-x.y.z-3_source.changes’ contains all changes beginning with ‘foo-x.y.z-1’, as I've done with this package? I must agree with others in this forum that it's easier to track the differences between different releases if they actually have different release numbers. > And before I forget to ask, why do you want this package to get into > Debian? The upstream author is making an effort to provide a standard interface for Python lockfile semantics, which are currently rather fragmented in the standard library; I think this implementation and interface is good, and want to see this succeed. Also, I intend to make use of this package as a dependency for another one of my packages in future. > debian/rules: > - There is a char in line 23, which should not be there Normal white space: ASCII FF, a page break. I use them because they are useful for navigating a text file “by page” in the editor. > debian/copyright: > - Update to the latest revision of the specification I have been following the progress of the specification, and haven't seen any format changes that would affect any copyright file I work on. Can you point out the changes that affect this copyright file? > - Indent with one space, not with 4 spaces What's the reasoning for that? Any indentation is sufficient for conforming with the format specification (since it's sufficient for conforming with the RFC2822 field format). Given the choice, I prefer to indent with 4 columns. Thanks very much for your feedback on my work. -- \ “I disapprove of what you say, but I will defend to the death | `\ your right to say it.” —Evelyn Beatrice Hall, _The Friends of | _o__) Voltaire_, 1906 | Ben Finney -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
