Ville Skyttä wrote:
I don't personally care where the spec templates come from, but I'd like all of them be generateable by fedora-newrpmspec. Its pre-filling capabilities are pretty limited kludges at the moment, and sounds like your stuff is capable of much more already, so as long as the result meets the guidelines, I'd be glad to apply patches that add such a hook.
OK, great. I think you'd have a hard time replicating the *potential* pre-filling capabilities of PEAR_Command_Packaging, since it's intimately tied into PEAR and knows how to analyse the package's XML file, work out deps etc.
In fact what I didn't mention before is that it does of course also auto-generate the Requires:, which is a major bonus.
As soon as we're all settled on a template spec, high on my priority list will be making php-pear-PEAR_Command_Packaging generate specs that comply with that template format, including upstream changes if required (although hopefully the development has reached a sufficiently advanced stage now that upstream changes should be minimal or zero; most can simply be achieved by patching/replacing the template.spec provided by php-pear-PEAR-Command-Packaging in %{peardir}/data/PEAR_Command_Packaging/template.spec)
From the hook POV, it would be easiest if "pear make-rpm-spec" would
take the package name in a command line option, and would be capable of emitting the generated template to stdout, perhaps conditionally based on existence of some other command line option. Maybe it already works that way?
Nearly. Currently it takes the *filename* of a package tarball and outputs the resulting template to stdout. Bear in mind that to do all the clever stuff it does, it needs to have a copy of the actual package tarball, not just the package name. But then if you're about to build an RPM, you're going to need this anyway...
If there was enough demand I could build in a hook to go off to pear.php.net and download the package tarball given a package name, but unless there's a compelling reason this is probably adding unnecessary complexity when a "wget" prior to calling make-rpm-spec will do the trick.
I wouldn't like a dependency on pear in rpmdevtools, so on pear execution failures (eg. when not installed), newrpmspec should probably just fall back to the generic template.
Fair enough; I'd had the exact same thought. In that case, there should probably also be
a) an informational message telling you that this is happening
b) a way to get newrpmspec to use the generic template *in any case*, so that if (for some weird reason) you don't want to download the actual PEAR package and just get a template spec based on the package *name* alone, you can.
Tim