This is a companion package to the package submitted in bug 172677 and is
intended to be an explicit Requires of that package (so that yum will pull this
in when perl-Readonly is requested)

I'm putting this in as blocking 172677 because if it fails to build on a
supported arch and can't be fixed, 172677 will need to be changed so that it can
ifnarch the  broken arch before it can be built.

Review:

- rpmlint clean
- package and spec naming OK
- spec file written in English and is legible
- sources match upstream
- package builds OK on FC4 (i386) and in mock for rawhide (i386)
- no locales, libraries, subpackages or pkgconfigs to worry about
- not relocatable
- no directory ownership or permissions problems
- no duplicate files
- code, not content
- %clean section present and correct
- macro usage is consistent
- no large docs
- docs don't affect runtime
- no desktop entry needed
- no scriptlets

Needswork:

- license is same as perl (i.e. GPL or Artistic), not just Artistic
- redundant BR perl (listed in exceptions section of packaging guidelines)

Suggestions:

- minor change to %description:

  Readonly::XS is a companion module for Readonly, to speed up read-only
  scalar variables.

Note:

- version 1.04 of this module is now available, and presents a couple of issues
if you're considering updating this package:

* The "Requires: perl-Readonly = %{version}" won't be satisfied because there is
no 1.04 version of perl-Readonly

* The Makefile.PL introduces a buildreq on Readonly, which will be a circular
dependency since your perl-Readonly package requires perl-Readonly-XS

Ouch.
I guess I'm going to have to remove the requires from the other package, which
is unfortunate because it means yum won't automagically pull in this one.

Updated src.rpm and spec file:

http://mpeters.us/fc_extras/perl-Readonly-XS-1.04-1.src.rpm
http://mpeters.us/fc_extras/perl-Readonly-XS.spec

- Builds fine in mock (FC4 i386)
- Review issues addressed

Strictly speaking the buildreq should be perl(Readonly) >= 1.02 (see
Makefile.PL) but it doesn't really matter as no older version has ever been
released in Extras.

Approved.

imported into CVS, owners list update.
Build request failing in devel, looks like broken rawhide dependencies (job
fails in setting up root)

Will close if/when build succesful in FC3/FC4 branch

(In reply to comment #4)
> I guess I'm going to have to remove the requires from the other package, which
> is unfortunate because it means yum won't automagically pull in this one.

I still think that bundling these two would have been acceptable in this case
and would have personally gone that way.  Sure, there are arguments why doing so
isn't that nice, so it's a matter of the maintainer picking his poison.  (Well,
when unbundled, some of that pain is outsourced to end users as non-obviousness.)

(In reply to comment #8)

> when unbundled, some of that pain is outsourced to end users as non-obviousness.)

Yeah - I agree - users have to know they need to request this to get the speed
bump. Too bad rpm doesn't have a "Suggests" tag to install if configured to do
so, or ignore if configured to do so.

Build machines could ignore it, but end user machines could (by default) install
it if available - but not choke and die if not available.

fc5 build system still not working (for any binary package) - package
succesfully through system on FC-4/FC-3.