> Neil Williams wrote: > > Can I have an assurance that &inhibit_log; will be retained - compatible > > with current behaviour - in future versions > > No. Dh_Lib is not a general-purpose library, it is a factoring out of > common code that debhelper programs use. Its behavior can and will > change in the future as it has in the past. (It used to be a shell > library..)
:-( > > You might as well claim that devscripts would be disallowed from using > > Debhelper::Dh_Lib. > > I can certianly see no reason for it to do so, since debhelper programs > are out of devscripts' scope. ? debuild ? (upon which emdebuild is based) ? > > 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. > > Useful code could always be moved from Dh_Lib to a true general-purpose > perl module, such as some of the ones in dpkg-dev. which is now frozen for Lenny. Joey, I need a solution to this bug in the next day or so because I need to upload a fixed version of emdebian-tools that can work alongside debhelper (>= 7) in order to fix a release-goal bug in another part of the package. I have no desire to either reinvent Debhelper::Dh_Lib or suffer continuous breakage because of this bug. Whatever the solution, it must allow the fixed emdebian-tools package to migrate into Lenny without needing a freeze-exception. Can you at least assure me that &inhibit_log will retain current behaviour until the Lenny release? That would at least allow me to workaround this bug until the common code can migrate into dpkg-dev alongside a lot of other code from dpkg-cross, Debian::DpkgCross, Cache::Apt::* and Emdebian::Tools? There is scope here for general purpose support, I agree, but that simply isn't going to happen before Lenny. If you are unwilling to fix this bug by making &inhibit_log the default when the module is loaded then I need to be able to rely on current &inhibit_log behaviour until such time as *all* relevant common code can be migrated into dpkg-dev *and* migrated into testing - after Lenny. -- 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
