[fedora-arm] F15 package dependency graph

[Peter Robinson]

On Sun, Jun 5, 2011 at 1:54 AM, Chris Tyler <chris at tylers.info> wrote:
> 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.

It must be stored in the database somewhere as you can get it from the
source parameter so I would assume/hope its just a matter of
extracting the appropriate value from a DB somewhere, it could
probably be done with the python bindings if I only knew python better
:-)

Peter

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=3108070