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
> 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
> 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*,
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