> Therefore I'd rather like to add --enable-final as a DEB_BUILD_OPTION in the > debian/rules files in the CVS modules rather than having it enabled globally.
Sure, but for the modules I maintain I'll be using --enable-final by default in debian/rules, since (i) as the maintainer I want my build environment to be the same as used by others (including buildds, etc), (ii) I have an old machine and so --enable-final makes a difference to me, and (iii) it won't break anything since when I add --enable-final I'll be patching the sources to remove any resulting errors. Moreover, I'd suggest that we use --enable-final by default across all kde*/debian/rules files, since (i) we as the maintainers of formal KDE modules will know what we're doing, (ii) we all have commit permissions and so will be able to patch any compile errors, and (iii) passing --enable-final in debian/rules won't propagate to 3rd-party apps either through admin/ or through the dh_make template. This solution is most pleasing to me since it satisfies my desire for an --enable-final KDE build and yet resolves the 3rd-party app / 3rd-party packager problem that you have identified. > Enabling it again when HEAD gets packaged is ok with me but for now until > december it doesn't make much sense to have it enabled anyway. Sure, I won't even be looking at it until we get to packaging HEAD. I probably wouldn't even be arguing so much now, except that I anticipate that when I do prepare KDE 3.2 packages and add --enable-final to debian/rules, there will be arguments about inconsistencies between defaults in different modules. In other news, koffice-i18n has just been accepted, so it should be good for sarge. b. :)
