Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes

Kevin Fenzi kevin at
Tue Sep 20 20:59:46 UTC 2011

On Tue, 20 Sep 2011 15:19:29 -0400 (EDT)
Doug Ledford <dledford at> wrote:


> > 2) 9 times out of 10 there was very little data put into the ticket.
> Multiple options here.  Kick back incomplete tickets, or the better
> option IMNSHO, run rpmdiff runs between the package currently in the
> compose and the one in testing to check for various failures and
> require the developer to justify failures.

Which rpmdiff are we talking about here? 
The free/included in fedora one is not that great... it gives you files
and deps that changed, but that doesn't help you see what changed in
> > 3) releng folks were often not the best people to decide whether a
> > change was "too risky"
> The rpmdiff option above would help with this.

So, I run it on xfwm4 updates: 

rpmdiff xfwm4-4.8.1-2.fc15.x86_64.rpm xfwm4-4.8.1-3.fc16.x86_64.rpm

removed     REQUIRES  
removed     PROVIDES xfwm4(x86-64) = 4.8.1-2.fc15
added       PROVIDES xfwm4(x86-64) = 4.8.1-3.fc16
S.5.......T /usr/bin/xfwm4
S.5.......T /usr/bin/xfwm4-settings
S.5.......T /usr/bin/xfwm4-tweaks-settings
S.5.......T /usr/bin/xfwm4-workspace-settings
..........T /usr/lib64/xfce4/xfwm4
S.5.......T /usr/lib64/xfce4/xfwm4/helper-dialog
...all the doc files have different timestamp...

What does that help me with? ;) 

> > 4) There was no easy way to get at the package and assess its
> > stability.
> Using bodhi instead of trac solves this, no?

well, not bodhi, but a repo like updates-testing, yeah. 

> > I think there were more issues, but those come to mind first.  We
> > decided it was best instead to make a repository out of proposed
> > changes,
> But in practice that's not really what updates-testing on the early
> branched release really is.  It's a repo all right, but not of
> proposed changes, it's a repo of packages, and getting to the actual
> changes versus the final package would require installing the current
> source rpm, the new source rpm, then doing a manual inspection for
> changes.  An automated rpmdiff run would be a *far* superior means of
> presenting the proposed changes to the community.

I'd love to see something more detailed from rpmdiff. ;) 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : 

More information about the devel mailing list