On Wed, 2008-04-30 at 15:16 -0400, Joey Hess wrote: > Neil Williams wrote: > > All debhelper commands assume they run in the top-level directory of the > source tree of the package to build. > > Dh_Lib is also not a general purpose library. It is intended only to be > used in building debhelper programs.
Well, if you're sure. Seems more than a bit odd to me though - maybe Debhelper::Dh_Lib should have a manpage (3) that mentions this design restriction. > > Please reset the log behaviour so that it is, by default, off and only > > enabled by specific executables, not modules. > > The logging is intended to also be done for third-party debhelper > programs that use Dh_Lib as designed, such as dh_pysupport. Enabling it > in each program individually is the wrong choice. > > > There could be a variety > > of multi-build scripts out there that will break in this way. > > I cannot imagine why a non-debhelper program would have a good reason to > use Dh_Lib. Nor that there are many such programs. debhelper is integral to the majority of functionality in emdebian-tools. Just because it isn't part of the debhelper source package doesn't mean it is trying to use Debhelper::Dh_Lib in an unwarranted or spurious method. You might as well claim that devscripts would be disallowed from using Debhelper::Dh_Lib. Can I have an assurance that &inhibit_log; will be retained - compatible with current behaviour - in future versions so that I can safely depend on >= without future breakage? (and that inhibit_log actually does mean "abandon_all_logs_all_ye_who_call_me" rather than "inhibit" in the sense of "reduce but still log sometimes"?) My particular need is that calling inhibit_log strictly enforces that Debhelper::Dh_Lib does not mangle the exit value of scripts using the module. I still think it is wrong for a module to mangle the exit value of a script using that module - especially when that exit value is zero and the module forces it to be non-zero. At the very least, such behaviour should be opt-in not opt-out, relative to previous versions. I'm not using Debhelper::Dh_Lib as a general purpose perl module, I'm using it to ease the process of cross-building Debian packages that use debhelper, specifically, parsing of control data, detection of native packages and other functions within the Emdebian::Tools module. It is particularly useful when the package does not already exist in the relevant apt cache because it is yet to be uploaded to Emdebian. I don't want to have to duplicate Debhelper::Dh_Lib and embed a forked copy in Emdebian::Tools just because the module mangles the exit value or creates spurious generated files. > Current guess at > total number: exactly 1. This one should be fixed. Fixed? The bug isn't in emdebian-tools - the bug is that a module mangles the return value of the executable. How is that a bug in my package? Please explain how emdebuild can be "fixed" to prevent a module from mangling the exit value? -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
