Bug 225616 - Merge Review: bison
Merge Review: bison
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Gwyn Ciesla
Fedora Package Reviews List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-31 12:45 EST by Nobody's working on this, feel free to take it
Modified: 2008-09-15 12:00 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-15 12:00:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
limburgher: fedora‑review+


Attachments (Terms of Use)

  None (edit)
Description Nobody's working on this, feel free to take it 2007-01-31 12:45:53 EST
Fedora Merge Review: bison

http://cvs.fedora.redhat.com/viewcvs/devel/bison/
Initial Owner: roland@redhat.com
Comment 1 Gwyn Ciesla 2008-02-06 11:48:30 EST
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.
Comment 2 Gwyn Ciesla 2008-05-16 11:04:01 EDT
Any updates?
Comment 3 Gwyn Ciesla 2008-09-08 15:42:41 EDT
Re-examined most recent rawhide build, no changes to above issues.  Adding current pacakge owner to CC list.
Comment 4 Petr Machata 2008-09-15 09:54:02 EDT
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.
Comment 5 Gwyn Ciesla 2008-09-15 10:29:46 EDT
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.
Comment 6 Petr Machata 2008-09-15 11:25:23 EDT
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.
Comment 7 Gwyn Ciesla 2008-09-15 12:00:57 EDT
Awesome.  Approved!

Note You need to log in before you can comment on or make changes to this bug.