Bug 173053 - Review Request: perl-Readonly-XS
Review Request: perl-Readonly-XS
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Howarth
David Lawrence
:
Depends On: 172677
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2005-11-13 02:01 EST by Michael A. Peters
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-13 12:47:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael A. Peters 2005-11-13 02:01:51 EST
Spec Name or Url: http://mpeters.us/fc_extras/perl-Readonly-XS.spec
SRPM Name or Url: http://mpeters.us/fc_extras/perl-Readonly-XS-1.03-1.src.rpm
Description:

perl-Readonly-XS is a companion module for Readonly.pm, to speed up read-only
scalar variables
Comment 1 Michael A. Peters 2005-11-13 02:06:00 EST
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 02:15:44 EST
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 06:26:33 EST
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
Comment 4 Michael A. Peters 2005-12-08 13:01:07 EST
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.
Comment 6 Paul Howarth 2005-12-08 13:49:41 EST
- 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.
Comment 7 Michael A. Peters 2005-12-08 14:29:04 EST
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 14:58:22 EST
(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 15:19:29 EST
(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 14:24:25 EST
fc5 build system still not working (for any binary package) - package
succesfully through system on FC-4/FC-3.

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