Bug 1381249

actually problem here is that some hand-written `./configure` will fail on this (I guess package "pseudo" was in my case).

That's possible, though I don't think anyone ever promised that %configure would never use autoconf-supported arguments outside of a particular limited set.  It's never been safe (or, really, acceptable) to use %configure for something that's not autoconf.

My main concern would be for ancient configure scripts; I honestly do not know how they would react, or how long this option has been supported.  Those have long been a problem in any case.

In either of these situations, the result would simply be build failures.  An easy workaround would be for a separate macro which could be used to control inclusion of the flag.

%configure is only intended for use with autoconf configure really, using it for anything else is just feeling lucky. However this has been tried before.

From redhat-rpm-config:
commit 8174ec3d109bbc61874d83b4fc77f19f2b76b05b
Author: Colin Walters <walters>
Date:   Tue Aug 9 10:42:06 2011 -0400

    macros: Globally add --disable-silent-rules to configure
    
    Various projects have been adding AM_SILENT_RULES from Automake to
    their Makefiles for "developer convenience"; the goal being that they
    see warnings more easily.
    
    Now really the right way to do this is to have a make wrapper (or an IDE)
    that knows how to filter out warnings, but let's leave that aside for now.
    
    But for debugging builds, we really need the full log data.  Being
    able to see exactly how e.g. libtool is being run helps a lot for
    debugging link problems as an example.

[fast-forward a few months]

commit 36225c3b7cda2f84793515d11f8df9c30b3bb3f2
Author: Dennis Gilmore <dennis.us>
Date:   Wed Nov 9 07:27:37 2011 -0600

    Revert "macros: Globally add --disable-silent-rules to configure"
    
    This reverts commit 8174ec3d109bbc61874d83b4fc77f19f2b76b05b.
    
    remove patch that forces --disable-silent-rules to configure it breaks anything set to not ignore unknown configure options

Heh.  Well, it could be time to revisit that.  With a macro to easily disable it, and some side tag rebuilds, it wouldn't be too hard to shake out the failures and fix them up.

Also, I am a bit confused about how that's in redhat-rpm-config; I was pretty sure the %configure macro is in /usr/lib/rpm/macros, which is part of rpm.  Has that macro moved around?  Not having to involve the rpm package itself in something like this is always a good thing; the packing committee will make changes to the various macros packages but I know I don't want to poke at rpm directly.

Well indeed I am being done; redhat-rpm-config does include its own %configure definition.  I had no idea; I thought it tried not to conflict with what RPM provided.  I guess I filed this against the wrong package, then.  Sorry for the trouble.

These things are like pendulum, one year people want to pull everything into distro specific packages and the next year they try to move it all into rpm again. Etc.

Bottom line is that there's no single right or wrong. The %configure in redhat-rpm-config contains things that wouldn't be acceptable in upstream rpm, but for things that make sense universally (ie outside Fedora/RHEL) we want to keep rpm's %configure in sync for the benefit of other distros etc.

Just for the record, I went ahead and added (in redhat-rpm-config) a conditional inclusion of --disable-silent-rules in the options passed to the configure script.  If %_configure_disable_silent_rules is defined, then that option will be passed.  I didn't define it by default, of course, so currently there's zero change in functionality.  The end result is that it can now be turned on with the flick of a switch (if FPC decides it wants to) and can be easily turned off by individual packages.  Or a packager can turn it on now if they want to.

I do wish we had some idea of just what it broke when it was reverted the last time, but eventually I'll do some complete Fedora rebuilds and get that all figured out.