Bug 197411 (php-pear-Date)
Summary: | Review Request: php-pear-Date - Date and Time Zone Classes | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Christopher Stone <chris.stone> |
Component: | Package Review | Assignee: | Jason Tibbitts <j> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Package Reviews List <fedora-package-review> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | Flags: | jwboyer:
fedora-cvs+
|
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-09-07 21:23:55 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 196802 | ||
Bug Blocks: | 163779, 197417 |
Description
Christopher Stone
2006-07-01 04:49:19 UTC
rpmlint complains: W: php-pear-Date dangerous-command-in-%post install but this is obviously bogus. Hopefully rpmlint will eventually be fixed to stop complaining about this as going to show up in every pear package. There seems to be a test suite included in the tarball. Is it possible to call it? It looks like many of the tests need an external mopdule called PHPUnit.php and I don't know enough about PHP to get the paths set up properly. The test suite question is the only thing that keeps me from approving this. The spec itself and the template it came from are quite clean and should work great in practise. * source files match upstream: 9acd7e19d094877c6d26be1fbabe79cb Date-1.4.6.tgz * package meets naming and packaging guidelines. * specfile is properly named, is cleanly written and uses macros consistently. * specfile follows the suggested PHP-Pear specfile template currently under development. * dist tag is present. * build root is correct. * license field matches the actual license. * license is open source-compatible. License text included in package. * latest version is being packaged. * BuildRequires are proper. * %clean is present. * package builds in mock (development, x86_64). * rpmlint has only bogus complaints. * final provides and requires are sane: php-pear(Date) = 1.4.6 php-pear-Date = 1.4.6-1.fc6 = /bin/sh /usr/bin/pear php-pear(PEAR) ? %check is not present, but there are some tests upstream. * package is not relocatable. * owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * scriptlets present are OK (PEAR module installation) * code, not content. * documentation is small, so no -docs subpackage is necessary. * %docs are not necessary for the proper functioning of the package. The rpmlint warning is mentioned here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198705 pear has no way to do a make check. It does include the test files in the rpm however. Hmm. It doesn't have a "make check" but there must be some way to run the tests. Also, I don't see the point of packaging the tests. Are they somehow useful to the installed module? However, for some reason some Python modules do the same thing, and it seems to be accepted, so I don't suppose it's a blocker. So, APPROVED I'm not sure, but the test dir is a standard php-pear dir and is defined in the macros, so I'm sure lots of packages have stuff there. But AFAIK, there is no standard way to run tests that are there. Perhaps we should assess the situation after more php packages have been approved and see if the tests directory is really needed. Branch Package CVS Request ======================= Package Name: php-pear-Date Short Description: Date and Time Zone Classes Owners: chris.stone Branches: EL-5 InitialCC: |