[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: xorg 7.2 for FC6



On Sat, 2007-02-17 at 13:01 +0100, dragoran wrote:
> Hello,
> Are they any plans for updated xorg packages for FC6?

In an ideal world, I'd like to focus on FC7 as much as possible, and
land that as an FC6 update once we're happy with it.  So, not yet.

Beyond that, it's a bit of a hassle to do this right now without manual
intervention from a brew guru, because the build system for updates
trees doesn't work the way I expect.  Essentially, the buildroot is
populated from dist-fc6-updates (which inherits from dist-fc6), but the
output of the build goes to a pile called dist-fc6-updates-candidate.
Packages normally only move from -updates-candidate to -updates once
I've filled out an update request and a release engineer has approved
it, which means a long propagation delay between building package A and
package B, when B BuildRequires a newer version of A than was in FC6.

(Ironically, modularisation of the X source made this worse!)

brew has a 'chain-build' command that _almost_ does what I want.  The
syntax is about what you'd expect:

brew chain-build a b c : d e : f

Which runs a b and c as a set, then d and e after the first set land in
the collection, and then f after the second set.  The reason it works
for rawhide is that it creates a new buildroot for every package, but in
rawhide the build output collection is the same as the collection you
create the buildroot with.  In other words, my buildroot is constructed
from dist-fc7, and successfully built packages also go to dist-fc7.  For
updates this isn't true.  Updates buildroots are created from
dist-fc6-updates, but the built package goes to
dist-fc6-updates-candidate.

What I need, I think, is a way to tell brew (possibly mock) to keep a
buildroot around for multiple related jobs, with an additional "update"
phase corresponding to the :'s above, in which the output of the
previous passes become available for use as BuildRequires.  This would
be useful outside the scope of updates too; say I wanted to fix a .pc
file to list fewer needless libraries, and I wanted to rebuild
everything downstream of that package to verify that they all still
build.

- ajax


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]