Hi there, I apologise if I seemed abrupt yesterday. I got a new Lintian from unstable and it found your problems too. On Sun, Jul 04, 2010 at 07:48:08AM +0200, Giovanni Mascellani wrote:
Il 04/07/2010 01:13, Iain Lane ha scritto:Hello, Thanks for your review.Hi, I'll add some more specific comments.missingh: * source/format: you're setting it to 1.0; are there any specific reason for not use 3.0 (quilt)? If not, I'd say 3.0 it's more recommended.No, I just thought that setting 1.0 would be the more minimal change. I don't understand what the point of 3.0 (quilt) is without any patches is, but please change it yourself before uploading if you want to.If you prefer it, I'm fine. I think that not using 1.0 anymore could allow the Debian project to drop the support for it (which would lead to less work for those who work on archive-related tools and similar), but probably there's no particular rush for it.
This is somewhat controversial and unlikely to change for a very very long time. See some responses on debian-devel@ — many people aren't happy with the way that this is handled :).
* control: there are some missing substitution variable (dpkg-gencontrol complains that some of them are not used); TTBOMK, you should use: - dev: Depends: ${haskell:Depends}, [...] Probably, the Haskell Policy should be updated (and not only for this reason). Maybe I can find some time next week to have a look at it.This feels somewhat like I'm being punished for problems that I didn't introduce.Sure, you didn't introduce problems, and this was really not meant to punish you. But, as I said in my last email, having these fields enable us to use hash-based dependency, which prevents us from having problems related to using a library linked to the wrong version of another. After all, they're not that big work, so I think it is a good practice to add them if they're not present when modifying a team maintained package.
Here I must apologise again! I missed the fact that Provides isn't there; I thought you were just asking me to add the Suggests and Recommends.
* About the fact that libghc6-missingh-doc is substituting missingh-doc: reading policy 7.6.2, my understanding is that Conflicts is more appropriate than Breaks (because the old package must be completely removed). Why are you changing it?I actually asked about this in #-devel and, since policy 3.9.0, it seems that Breaks: is preferred. So I think we're alright here.Fine.* There are some lintian suggestions that you may want to follow (are you aware of the -I and --pedantic options? Sometimes they're really too pedantic, but usually they can give you good hints). All I: and P: are completely optional, but there are also two W: that you should fix (BSD is not anymore in common-licenses; I suspect this is due to the fact that there are many different BSD licenses, so saying "BSD" isn't clear: it's better to copy the verbatim text).I didn't look at these, but rather did the specific changes I was trying to achieve, in addition to some low hanging cleanups.Again, my opinion is that, in team maintaining, when you find some previous problems in a package, you also try to fix them (and lintian W:s related to debian/copyright are problems, given the importance that d/copyright has for Debian). Anyway, if this really is unacceptable for you, we can go on.
No, it is just that the problems I found weren't really (easily) fixable, but your lintian ones are so I've done that.
haskell-configfile: * lintian: as before (but without W:s)P: libghc6-configfile-dev: no-upstream-changelog P: libghc6-configfile-doc: no-upstream-changelog I: libghc6-configfile-doc: possible-documentation-but-no-doc-base-registration Don't know what you want me to do about this.I've much more of them:$ lintian -I --pedantic haskell-configfile_1.0.6-2_amd64.changes [...]As I said, nothing terrible here. I think that at least the easy things (d/watch and the first two) could be fixed, but we can ignore this too.
About the additional W: about the BSD license in missingh, I can't find those licenses. And the one in the source tarball is just a copy of the file in common-licenses :(. The copyright file does enumerate the translation needed, but I'm not comfortable claiming this as the upstream license so won't modify it myself.
* package descriptions: I don't know what you mean with "DHG consistence", but don't like very much the initial paragraph you have put in all the descriptions (it could be the last, maybe; the first paragraphs should give a general idea of what the package do, not where to find information about the language it is written with). Is it really a best practice to have such a preamble? (this question, of course, is for the full mailing list).I copied this from another package (mtl). I thought it was common across group packages. Maybe not.I thought it wasn't. Well, this will require more general discussion in the DHG, so far we can leave your description as you put it. As promised, today I think I'll have time to finish the review and upload.
btw, I looked at your hslogger upload to steal ideas and noticed a couple of things
- Build-depends need bumping, particularly on haskell-devscripts, to the version that provided substvar support (0.6.19 or 0.7)
- in -doc, you have ${haskell:Depends} in the Recommends field
- No BD on ghc6-prof
- Priority → extra
btw2, -dummy still needs uploading. I hope this one is more
straightforward.
Iain
Attachment:
signature.asc
Description: Digital signature