Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at

Bug 173053

Summary: Review Request: perl-Readonly-XS
Product: [Fedora] Fedora Reporter: Michael A. Peters <mpeters>
Component: Package ReviewAssignee: Paul Howarth <paul>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fedora-extras-list, perl-devel
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-12-13 17:47:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 172677    
Bug Blocks: 163779    

Description Michael A. Peters 2005-11-13 07:01:51 UTC
Spec Name or Url:
SRPM Name or Url:

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

Comment 1 Michael A. Peters 2005-11-13 07:06:00 UTC
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)

Comment 2 Michael A. Peters 2005-11-13 07:15:44 UTC
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.

Comment 3 Paul Howarth 2005-12-08 11:26:33 UTC

- 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


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


- minor change to %description:

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


- 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

Comment 4 Michael A. Peters 2005-12-08 18:01:07 UTC
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.

Comment 6 Paul Howarth 2005-12-08 18:49:41 UTC
- 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.


Comment 7 Michael A. Peters 2005-12-08 19:29:04 UTC
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

Comment 8 Ville Skyttä 2005-12-08 19:58:22 UTC
(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.)

Comment 9 Michael A. Peters 2005-12-08 20:19:29 UTC
(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.

Comment 10 Michael A. Peters 2005-12-12 19:24:25 UTC
fc5 build system still not working (for any binary package) - package
succesfully through system on FC-4/FC-3.