Fedora rawhide rebuild in mock status 2009-06-08 x86_64

[Chris Weyl]

On Sat, Jun 13, 2009 at 12:55 AM, Iain Arnell <iarnell at gmail.com> wrote:

> On Thu, Jun 11, 2009 at 12:06 AM, Matt Domsch<Matt_Domsch at dell.com> 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-sig
>
> These 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-perl-devel-list/attachments/20090613/a32ec0fe/attachment.htm>