Post by Daniel LintottI'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)
Post by Daniel Lintottdebian/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 theres a mechanism by which PHONY targets are no longer necessary? Or just that since those files arent present in the source directory, theyre 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 theres 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
Post by Daniel Lintottdebian/control
- section can be removed from libiniparser0 binary package
I know its 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.
Post by Daniel Lintottdebian/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 its 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 theres any lintian checks that already look for deprecated watch file formats.
It may be worth suggesting that to the Lintian developers
Post by Daniel Lintottdebian/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, Im 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 theyre 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
Ill 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
Post by Daniel LintottI 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
Im happy to maintain it. Just wanted to extend the offer.
No problem ;)
Regards
--
Daniel Lintott
GPG Key: 4096R/5D73EC6E