Hi! On Fri, 2014-08-29 at 16:52:06 -0700, Enrico Zini wrote: > Package: dpkg > Version: 1.17.10 > Severity: wishlist
> currently, dpkg-maintscript-helper's manpage documents creating various > maintainer scripts to run it. > > It turns out that dh_installdeb has support for doing that > automatically, and it should be preferred to manually maintaining > scripts. > > Can you please mention in the manpage that the right way to invoke > dpkg-maintscript-helper should be via debian/package.maintscript? Hmmm, this is the second time this gets filed, so I guess there's something to be fixed on the debhelper side too, otherwise people would be able to find how that's supported there in an easier way. It may need to be mentioned in debhelper(1) for example, as dh_installdeb(1) may not seem obvious to people. In any case, as last time, on one hand I'm not entirely thrilled about adding such upper layer descriptions directly to dpkg, please see #676318 for my rationale at the time. But on the other hand I acknowledge that dpkg-maintscript-helper, even if it's a collection of unintegrated hacks anyway, is there to make people's life easier, so "polluting" the man page with helpful information would be just a minor sin on top of the current situation. And I realized just now that several dpkg man pages are already describing stuff from upper layers, so currently holding such stance on purity might not seem to make much sense anyway. :/ Do you think a generic wording would have been enough? Something along the lines of: "When using a packaging helper, please check if it has native dpkg-maintscript-helper integration, which might make your life easier." It could also be accompanied with a link to the wiki, where any such packaging helper can be described at length, in a similar way how dpkg(1) currently links to the <https://wiki.debian.org/Teams/Dpkg/FAQ> to expand on how to handle the --set-selections issue with several tools. So in addition something like: "Please see <https://wiki.debian.org/Teams/Dpkg/FAQ> for helper specific examples on how to integrate this program with a package." Obviously this has the disadvantage of not being available off-line. Otherwise, if these do not seem helpful enough, I guess I'd be willing to budge and add a direct description. Thanks, Guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
