[fedora-arm] F15 package dependency graph

[Chris Tyler]

On Sun, 2011-06-05 at 00:07 +0100, Peter Robinson wrote:
> On Sat, Jun 4, 2011 at 11:09 PM, Jon Masters <jcm at redhat.com> wrote:
> > On Sat, 2011-06-04 at 16:40 -0400, R P Herrold wrote:
> >> On Sat, 4 Jun 2011, Jon Masters wrote:
> >>
> >> > Oh, it can all be done :) I'm just curious what exists already. Perhaps
> >> > Dennis can help fill in some gaps here. Also, I know of at least one
> >> > script already I've pinged someone else about.
> >>
> >> umm -- in rpm-devel package, rpmgraph has been present for a
> >> long, long time
> >
> > Thanks for the pointer. I actually didn't know about rpmgraph. I
> > probably should have, and now I do :) This gives the kind of data I am
> > looking for as a good starting point. I'd like to take all of the F15
> > packages and prepare some graphs to look at/discuss before Friday. In a
> > perfect world, we'd have dependency data on packages so we can exclude
> > non-bootstrap bits (functionality we don't need for bootstrap), but that
> > data isn't available, so we'll have to cull the graph a little manually.
> >
> > One of the outcomes I would like to see from the ARM v7 bootstrap is
> > better documentation on new arch bringup for Fedora, since this is
> > unlikely the last time it'll happen in general. Graphing and determining
> > necessary orderings for rebuilding the universe is part of it. I'm also
> > curious what the mass-rebuild rel-eng efforts use to do ordering (not
> > quite the same problem but they must use something for this, Dennis?).
> 
> When I've asked about build ordering in the past I've got the response
> in that there isn't any (not answering for dennis here) and they
> basically build the core required bits and then set off the mass
> rebuild. The scripts they've used in the past are in the host-eng trac
> git so that should give you some more details.
> 
> I'm also interested in some other central tools and scripts that would
> make it easier for secondary arches. It seems they all have useful
> tools that aren't generally available. Some ideas I've had or seen
> other secondary arches use are:
> 
> - I've seen the PPC guys produce some cool graphs of the difference
> between release X and their arch.
> 
> - A script to import noarch packages into the secondary koji instance
> would useful. At the moment you end up downloading all the packages of
> a particular spec (assuming you know its completely noarch), importing
> and tagging them. To have something like "blah --importnoarch dist-XX
> NVR" as well as to do all noarch for a particular tag (possibly
> something to shadow import too).

The problem I see with importing all the noarch packages en masse
without other filtering is that there are SRPMs that produce both
arch-specific and noarch RPMs, and you'll end up with just the noarch
pieces imported, possibly mismatched with the arch-specific pieces.
We've seen this through the F13 cycle using the
build-previous/koji-shadow tools.

> - A way to build an NVR for a tag on secondary. At the moment there
> doesn't seem to be any easy way to do this. You can clone the
> package's git and use fedpkg. Post git you can get the git url from
> koji. Even a couple of commands that you can chain would be useful.
> Something like "koji buildurl tag NVR" to return the git:// which you
> can then feed to something else. It saves a lot of time of either
> unnecessarily cloning 1000s of package repos or trolling through koji
> to work it out.

The challenge with fedpkg/git is that, as far as I can see, it's not
obvious which commit corresponds to a particular NVR; you'd probably
have to switch to a particular branch and walk backward through the
commits until you find the right ENVR in the spec file.

On the other hand, it's fairly straightforward to grab the right SRPM
from the koji package archive as build-previous/koji-shadow do; we're
using the same approach in styrene.

-Chris