On 7/26/06, Toshio Kuratomi <toshio(a)tiki-lounge.com> wrote:
Nope. We should try not to purposefully stick our hand in any
fires.
If we find a problem, it should be fixed, but promoting practices that
we know risk triggering bugs when there are simple, straightforward, and
clean ways to code it instead is just good sense.
I don't see this as sticking a hand in a fire. It is simply the fact
that removing %build does not affect php-pear packages, there is no
reason to add it. If not adding it causes some problem with the
php-pear packages, then this should be identified. So far no one has
identified such problem.
We should not try to do preemptive maintenance on our spec files and
add a bunch of extra cruft just because one problem occurred in a
package that has binaries. If there is a problem with binary packages
not using %build, then this should be fixed. You can patch this spec
file temporarily with a %build until the problem is fixed, but don't
start imposing standards on other spec files that do not have this
issue.
Until a problem is identified with php-pear packages, no %build should
be added. If a problem is identified, then the problem should be
noted as a bug and then we can add %build to the spec files.
There has not been any indication as far as I can see that not
including %build is going to cause unpredictable results in any way
other than not building a debuginfo package which is not required for
php-pear packages anyway.