rpmlint on srpm:

bison.src:148: W: macro-in-%changelog defattr
Macros are expanded in %changelog too, which can in unfortunate cases lead
to the package not building at all, or other subtle unexpected conditions that
affect the build.  Even when that doesn't happen, the expansion results in
possibly "rewriting history" on subsequent package revisions and generally
odd entries eg. in source rpms, which is rarely wanted.  Avoid use of macros
in %changelog altogether, or use two '%'s to escape them, like '%%foo'.

bison.src: W: summary-ended-with-dot A GNU general-purpose parser generator.
Summary ends with a dot.

Fix.

rpmlint on rpms:

bison.i386: W: devel-file-in-non-devel-package /usr/share/bison/yacc.c
A development file (usually source code) is located in a non-devel
package. If you want to include source code in your package, be sure to
create a development package.

bison.i386: W: devel-file-in-non-devel-package /usr/share/bison/glr.c
A development file (usually source code) is located in a non-devel
package. If you want to include source code in your package, be sure to
create a development package.

bison-devel.i386: W: no-documentation
The package contains no documentation (README, doc, etc).
You have to include documentation files.

bison-runtime.i386: W: no-documentation
The package contains no documentation (README, doc, etc).
You have to include documentation files.

Fix or explain in spec.

Is the .a necessary, and if so, why in -devel, not in -static?

Otherwise, looks great, no other blockers.

Any updates?

Re-examined most recent rawhide build, no changes to above issues.  Adding current pacakge owner to CC list.

Committed a cleaned-up version into rawhide.  No build done.

* Fixed the dot in summary and %-escaped macros in changelog

* Source files in main package are needed in run-time by M4.  They don't belong to separate devel package.

* That runtime package lacks documentation... well, it does, but then these are just language files that the parser needs during the runtime.  If you think that a note is necessary, I can write something up, but given it's just a package-dependency package, and not strictly a user-facing package, I'm inclined to just leave it alone.  Similar for devel.  Please advise.

* That .a is packaged at all: this case is similar to .a packaged with flex.  It's a tiny library, with just 'main' and 'yyerror' symbols in that.  It's extremely stable, these functions are just a couple lines of source code, hence the overhead of introducing dynamic library outweighs the benefits.  Some users still use these instead of providing their own defs, I know I got my share of complaints when I dropped .a from flex.

* That .a is part of -devel.  Well, it could be -static, but the split was done in Jan 2005, which predates current guidelines regarding the same.  I can see a logic in that: the library is devel in the sense that the generated parser could be distributed together with other sources, and only bison-devel would be necessary to wrap the build.  (Although I'll admit it's kinda fuzzy reasoning.)  Again, please advise.

FWIW, 144 packages depend on bison in F9, and nothing on bison-devel.

I think this all makes sense.  I'd like to see notes in the spec on these, to avoid future confusion.  Then we're good.

The stuff about runtime and devel is written directly in the description of respective subpackages.  I've included a commentary explaining the reason for static liby and naming of devel.  It's in the CVS.

Awesome.  Approved!