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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
