On Sat, Jun 13, 2009 at 12:55 AM, Iain Arnell <iarnell@xxxxxxxxx> wrote:
On Thu, Jun 11, 2009 at 12:06 AM, Matt Domsch<Matt_Domsch@xxxxxxxx> wrote:
> Fedora Rawhide-in-Mock Build Results for x86_64
> perl-Catalyst-Action-RenderView-0.10-2.fc12 (build/make) cweyl,perl-sig
...snip...
> perl-Catalyst-View-TT-0.29-1.fc11 (build/make) cweyl,perl-sigThese should be okay now (probably - I didn't check them all). There
was a missing Requires in perl-Catalyst-Runtime.
Argh. Its things like this that reinforce how... ineffective our Perl req/prov scripts often are. They're usually ok at picking up standard use/package, but not so good with everything else. And in situations like this, where the scripts have _no_ idea how to deal with Moosey 'with' or 'extends' statements, the dependency just get missed entirely.
We have all this wonderful build/test/configure/runtime dependency metadata in META.yml -- with Catalyst-* dists especially -- and future MYMETA.yml/json coming down the pike, that it makes me wonder if we shouldn't move away from our dislike of providing explicit requires. If we explicitly required everything that the metadata said we needed, including the versioning, we'd:
1) have more reliable rpm dependency data;
2) not worry about missing something because the autoreq/prov scripts don't understand the syntax;
3) have more _versioned_ build/requires than we do currently; and help us
4) push dependency issues upstream, where they should be.
There are a couple different ways we could do this... The easiest (if more labor intensive) being to add explicit rpm requires for everything listed as such; and BR's for everything marked as build/configure/test requires. cpanspec already tends to do this if memory serves. I also have a little script I've been using to update spec files with CPANPLUS and META.yml; it wouldn't be difficult to add in checks for adding/updating requires lines too. This also has the advantage of keeping things external to the rpm build system; META.yml isn't always present, there are differing bits of information provided, and it sounds like we'll have a more consistent/CPAN-wide META.xxx at some point in the not too distant future.
Another way would be to use a macro to parse/generate dependency information from the META.yml directly. I've played around a little bit with this and the embedded LUA interpreter; I haven't found a good way to work with YAML files in LUA yet but JSON is pretty straight-forward. This might be a something we could implement once TPTB hash out the MYMETA.json standard. (The latest Module::Installs will actually generate this if you ask it nicely.)
This wouldn't need to be done everywhere, but I can think of some of the more complex packages (Catalyst-*, MojoMojo, anything using Moose, etc) where it would help keep correct dep info in place.
Thoughts?
-Chris
--
Chris Weyl
Ex astris, scientia
-- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
