On 18/05/14 00:40, Klee Dienes wrote: > On May 17, 2014, at 3:19 PM, Daniel Lintott <dan...@serverb.co.uk> wrote: >> I've taken a look at your packaging at agree it looks good. I noted a >> couple of things that I've picked up since I started packaging… > > Thanks for the feedback! I took most of your suggestions (comments to follow) > >> debian/rules >> - no need to define a .PHONY target >> - build flags import and set isn't required as dh9 sets all the >> required build_flags > > Removed the build flags stuff; thanks. > > Do you have a reference regarding the .PHONY target? Are you saying that > there’s a mechanism by which PHONY targets are no longer necessary? Or just > that since those files aren’t present in the source directory, they’re not > needed. Now that you have me thinking about this, I realize that debhelper > probably has a bunch of invisitargets that are never getting captured by > .PHONY. So I took the easy way and agreed with you and removed them all. > There is a *lot* of documentation out there that implies that they should be > present, though … I wonder if there’s a canonical source of guidance anywhere.
I don't have any reference per se.. other than I've not seen it used personally... (Doesn't mean I'm right btw) :P Just having a look the only reference I could find was at the beginning of the following message: https://www.mail-archive.com/pkg-clamav-devel@lists.alioth.debian.org/msg02836.html >> debian/control >> - section can be removed from libiniparser0 binary package > > I know it’s redundant, but it pains me to have all the other binary packages > specify a Section: and not libiniparser0. Ack... I noticed that it was flagged up by Lintian, so thought I'd suggest it. I'm not sure what the official view is. >> debian/watch (Attached) >> - Look at GitHub tags directly (not via deprecated github redir) >> - Add dversionmangle to remove date/git suffix > > Thanks! I wonder if it would be possible to add a note to > githubredir.debian.net explaining that it’s deprecated and giving the new > syntax. That may well be possible... Just looking at changelog for the devscripts package which contains uscan it contains the following: + Update the GitHub example. Based on a patch by YABUKI Yukiharu. (Closes: #728182) in version 2.14.0 (which is present in testing) > I also wonder if there’s any lintian checks that already look for deprecated > watch file formats. It may be worth suggesting that to the Lintian developers >> debian/changelog >> - Most new packages use a single entry in the changelog, for the >> initial packaging and closing of ITP bug > > That makes sense, but OTOH, I’m using these packages internally in my > personal work. So as I find bugs I am bumping the version internally … it > makes sense to me to keep meaningful changelog entries. Is there a reason > they’re considered harmful, or is it just a matter of personal preference? I > suspect you are right that I should push the “Closes: #738850” entry to the > release that actually closes the ITP … I’ll do that when I go to submit. I don't think it's necessarily considered bad, but something I've noticed a lot of Debian Developers require when they sponsor packages on mentors.debian.org >> I would be reluctant to take over the package entirely as I'm not really >> familiar with library packaging (other than perl modules). > > This one, thankfully, is a pretty easy one. No pressure was intended … I’m > happy to maintain it. Just wanted to extend the offer. No problem ;) Regards -- Daniel Lintott GPG Key: 4096R/5D73EC6E
signature.asc
Description: OpenPGP digital signature
