On Fri, 2006-06-30 at 12:49 +0100, Tim Jackson wrote:
Ville Skyttä wrote:
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.
Yeah, I thought so :)
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.
Hm, that could be somewhat problematic. newrpmspec takes the package name, so it would need to know how to transform that into a tarball filename including the full path to it, and including the possible version number in the tarball filename. newrpmspec's interface is not set in stone, but I'd prefer if one could continue to do for example "fedora-newrpmspec php-pear-Foo_Bar.spec" (and "emacs php-pear-Foo_Bar.spec") and everything would Just Work. Ideas?
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
That would be trivial to add.
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.
Already doable with the -t option to fedora-newrpmspec, see --help for details.