Spec Name or Url: http://fedora.ivazquez.net/files/extras/php-json.spec SRPM Name or Url: http://fedora.ivazquez.net/files/extras/php-json-1.1.0-1.src.rpm Description: php-json is an extremely fast PHP C extension for JSON (JavaScript Object Notation) serialisation.
As this package can be built with different "main" phps, IMHO it is better to do "phpize" (i.e., "phpize --clean" after untar to clear, and then "phpize" to create needed stuff). PHP-4.3.11 (FC3), PHP-5.0.4 (FC4) and PHP-5.1.1 (FC5) can have different phpize results. It seems that upstream developers already run some "phpize" (like an analogue of autotools), but it is more robust to rerun it for different php versions. Hint: %prep %setup -q -n php-json-ext-%{version} phpize --clean phpize %build %configure make %{?_smp_mflags}
Updated.
OK Remarks & nitpicks: - autodetection of extdir and version can be simplified a little (as good php-config always present in the Fedora's php-devel package) - Use %{?dist} in the release field (as this package hardly depends to specific distro's php version) - Remove leading "An" from the summary - Some %check section would be useful (at least to check that this module is successfully attached at run-time and is visible by the /usr/bin/php). See all these suggestions in the patch below. I am confused a little by the fact there is no any documentation in this package. Perhaps some data can be obtained from the upstream's site? (By simple copying some *.html files etc.)
Created attachment 122613 [details] suggested changes for the spec file
(In reply to comment #3) > - autodetection of extdir and version can be simplified a little (as good > php-config always present in the Fedora's php-devel package) Except when mock does its depsolving. > - Use %{?dist} in the release field (as this package hardly depends to specific distro's php version) I always add that once it's in CVS. > - Remove leading "An" from the summary Sorry, but I refuse to turn the Summary into grammatical garbage. Bring it up on the mailing list if you wish to discuss this. Updated.
> Except when mock does its depsolving. Not understood how mock can have issues here, but it is not a blocker :) > I always add that once it's in CVS. Why not before? IMO the PackageGuidelines requires it at review stage... Anyway, all other guys do it before CVS... - installed pam-json.html has execution bit set. Actually, "x" bit is set immediately after "install -p %{SOURCE1}". Perhaps changing "install" to "cp" can solve this. - Initially, I resisted to increase release numbers after each trivial change. But eventually various reviewers have forced me to do it always... ;)
(In reply to comment #6) > > Except when mock does its depsolving. > Not understood how mock can have issues here, but it is not a blocker :) mock looks at the bare spec file and evaluates it, possibly before any BRs have been installed. Try it some day. > > I always add that once it's in CVS. > Why not before? IMO the PackageGuidelines requires it at review stage... Anyway, > all other guys do it before CVS... Most all other guys don't have %dist defined on their system, and it gives the buildsystem conniptions if I import it with %dist as .fc4 and then try to tag in FC-4. > - installed pam-json.html has execution bit set. Actually, "x" bit is set > immediately after "install -p %{SOURCE1}". Perhaps changing "install" to "cp" > can solve this. No, this is because I misused install. Fixed. > - Initially, I resisted to increase release numbers after each trivial change. > But eventually various reviewers have forced me to do it always... ;) It's not supposed to be used by the public yet, so I figure no harm, no foul. Updated.
> it gives the buildsystem conniptions if I import it with %dist as .fc4 and then > try to tag in FC-4. make tag TAG_OPTS="-F" ... :) OK APPROVED.
Built on FC4 and devel