[Rpm-maint] [PATCH] Check for undefined macros

[Panu Matilainen]

On 02/13/2013 08:07 AM, Alexey Tourbin wrote:
> On Sun, Jan 27, 2013 at 05:27:09AM +0000, Alexey Tourbin wrote:
>> This change introduces a generalized routine rpmExpandMacros() to expand
>> macros on behalf of user input, with improved diagnostic facilities.
>
> This is actually the most important patch, because it unveils many
> typos/thikos in specfiles, and it can be instrumental in improving
> package base (as opposed to improving rpm code base proper, with no
> overt impact on the packages).
>
> Since Fedora 19 is in its early stage of development, and since RHEL7
> probably won't be using rpm-4.11+ anyway, I wonder whether this is the
> right time and otherwise a good idea to make a release with this patch
> applied (along with a few other patches related to syntax).  If it turns
> out to be a good idea, I'm willing to spend more time and come up with
> "full coverage" results for Fedora 18 specfiles (I have already posted a
> rather detailed if preliminary analysis of some common errors).

Hold your horses :)

I haven't gotten to looking at the patch in any kind of detail (I'm 
getting there, try be patient please), but just to set the expectations 
straight:

There's usually *at least* half a year lag of getting major rpm changes 
into any distro. Fedora or RHEL schedules do not dictate rpm.org 
schedules, nor are those the only consumers of rpm we need to take into 
account. Fedora rawhide is an important testing ground though, so I do 
try to align rpm.org releases to Fedora schedules.

With my Fedora maintainer hat on:

 From rpm POV, Fedora 19 is a done deal at this point, except for the 
inevitable bugfixes / 4.11.x maintenance release updates. The earliest 
release where changes of this scale could go in would be rpm 4.12 and 
Fedora 20 really. I've had enough of playing the "we should be able to 
slip this in just before deadline" games by now, new rpm major versions 
are only introduced in rawhide around the time previous Fedora version 
has just gotten branched and the schedule for the next one isn't even 
set yet, and generally needs to be considered stable well before the 
next branch occurs. So compared to the average Fedora development 
activities, we're always trying to be roughly three months early (or for 
alternative POV, one release late) to almost everybody else in landing 
new developments. When folks are trying to stabilize the rest of the 
distro, they dont want to (and shouldn't have to) be dealing with new 
rpm curveballs. The other side is my own sanity (or what's left of it ;) 
- I just dont want to play the mad and potentially risky dash to 
deadline when I can largely avoid it by simply aligning schedules a bit 
differently.

	- Panu -