Re: (forw) kde-common/admin
> 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. :)
Reply to: