Is really bodhi so stupid^H^H^H^Hnon-smart?

[Kevin Kofler]

Matej Cepl <mcepl <at> redhat.com> writes:
> Could you elaborate on this, please, or point to some 
> explanation? I don't understand how dist-f9-override works myself 
> ... :-(

The problem is that updates to released distributions don't automatically end 
up in the buildroots for dependent packages to build against. That's because 
updates may be revoked, so usually it is safer to build against the latest 
stable version in order not to introduce accidental dependencies on updates 
which don't actually get pushed. Only when an update moves to the stable 
updates, it ends up in the buildroot.

So until there it sounds all reasonable, but then where's the problem? Well, 
sometimes libraries break compatibility both ways, meaning a build against the 
old version will not run against the new one. (Usually, this happens when a 
library bumps their soname, Tcl is a bit special there, but it has the same 
effect.) Another potential problem is that you want to push a new version of an 
application using the library together with the new library version, but that 
new application version needs the new version of the library to build. (That's 
the regular situation for KDE.) And of course we don't want to push the update 
to the stable updates before the dependencies are being rebuilt (otherwise we 
end up with the problem which started this thread)...

So what now? This is where Release Engineering (rel-eng) enters into action. 
Rel-eng has the power to force packages from updates-candidate or 
updates-testing into the buildroot. They do this by tagging the package in Koji 
with an override tag for the distribution, i.e. currently dist-f9-override or 
dist-f8-override. The buildroot will prefer the packages with the override tag 
to the ones from (stable) updates (even if they're older, so it's important to 
remove the override tags when no longer needed, but rel-eng normally takes care 
of that). That in turn allows dependent packages to be rebuilt so they can be 
pushed all at once.

Thus, the workflow is as follows:
1. build the library (DO NOT submit an update yet!)
2. send an e-mail to rel-eng asking to tag the library with dist-f9-override
3. wait for rel-eng to (manually) process the request, you'll normally get both 
a confirmation mail from rel-eng and an automated tagging notification from 
Koji (the mail from rel-eng goes to whomever requested the tagging, the Koji 
notification goes to whomever built the library)
4. wait for Koji to complete its newRepo task (normally takes less than an 
hour)
5. build the package(s) depending on the new library
6. for more complicated dependency chains, repeat steps 2 to 5 as often as 
necessary
7. submit a grouped update with all the affected packages through the Koji web 
interface
(If you don't have commit access to the dependent packages, you should request 
it so you can do 5. and 7., otherwise some coordination with the other affected 
maintainers is needed.)

        Kevin Kofler