Bug#738850: ITP: iniparser -- a stand-alone INI file reading/writing library

[Klee Dienes <klee@MIT.EDU>]

On May 17, 2014, at 3:19 PM, Daniel Lintott <daniel@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.

> 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.

> 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.  I also wonder if there’s any lintian checks that already look for deprecated watch file formats.

> 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 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.