boost soname bump

Adam Williamson awilliam at
Wed Nov 23 01:04:48 UTC 2011

On Wed, 2011-11-23 at 01:49 +0100, Denis Arnaud wrote:

> I guess that you are referring to the following procedure:
>, aren't you? 

Pretty much, yep.

> Is an example of such a
> ticket?

No; that's someone using the old buildroot override process. You used to
have to file a ticket to request a buildroot override.

> Indeed, I understand that procedure as being kind of equivalent, in
> Rawhide, to the Buildroot Override procedure
> ( on branched
> releases. 

Well...not entirely. The two achieve sort of similar goals, but they do
have differences, and *both* exist for branched releases - it's not as
simple as 'tags for Rawhide, BROs for branched'.

A buildroot override is, kind of, the quick-and-dirty option: it just
stuffs a build that hasn't yet gone through the update process fully
into the main buildroot for a release. *All* builds for that release
will then build against that version of the package (and not the one
that's in stable) until the BRO expires. So it's slightly dirty, but
usually it doesn't really cause problems. It's intended to be used to
handle the classic case where you want to rebuild package A, then
rebuild packages B, C and D that depend on A, then submit A, B, C and D
together as updates. Without BROs you couldn't do this - you'd have to
send A through first, wait for it to go all the way through the updates
process, then build B, C and D after it was done.

A tag is a heavier, somewhat cleaner option: it's effectively a rolling
branch (I dunno if there's a more correct term for that) of the entire
release in question. It doesn't do anything slightly messy to the
official buildroot, like BROs do, but it does require rather more
resources, AIUI; we couldn't provide a new tag for every little BRO-type
situation, hence the BRO process. So tags are intended for bigger, more
complex dependency rebuild cases, especially 'structural' ones - ones
which come up over and over again. Boost fits that bill rather well.
What you'd do is apply for a 'boost' tag, which would always exist from
then onwards. When you had an ABI-incompatible boost change coming up
you'd build boost *and tag it into that branch*, not the main Rawhide
one (you can do this with fedpkg / koji). Then you could rebuild all
dependent packages with the same tag at your leisure, and once that
process was complete, tag the boost package and all the dependent
rebuilds with the main rawhide tag simultaneously. Done correctly, this
would mean there'd never be any dependency issue in the main rawhide
repo itself. (Tags can also be used just for working on some especially
experimental change you're not entirely sure you really want to land in
Rawhide, at least not yet - it gives you a way to try something and then
pull the plug if it turns out to go horribly wrong, without having to
revert and rebuild all your changes).

BROs don't exist in Rawhide simply because there's no updates process
for Rawhide - as soon as you send a build tagged for the main Rawhide
tree, it goes into the buildroot. So there'd be nothing for the BRO
process to *do* in Rawhide. But tags do exist, because the use cases for
them are still valid for Rawhide.

> Could we imagine extending that Buildroot Override procedure be
> extended, at least on Bodhi, to ask for Rawhide specific/sandbox tags?

See above :) the creation of tags isn't automated and I believe isn't
intended to be, for the reason that they're somewhat resource intensive,
while BROs aren't. So it's safe to let people create an essentially
unlimited number of BROs with no human in the loop, but for tags, you
kind of want that manual stage.

I'm sure releng will correct anything I got wrong there.
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | adamwfedora

More information about the devel mailing list