beryl: missing deps

[Michael Schwendt]

On Sun, 19 Nov 2006 19:37:17 +0100, Thorsten Leemhuis wrote:

> Rahul Sundaram wrote:
> >>> Clive Messer wrote:
> >>>> It looks like only some of beryl has been pushed to repo .......
> >>> Missing deps are under FE-Review or are waiting for FE CVS to
> >>> come back again to be rebuilt.
> >> Then why the heck was beryl build for FC-6 if it was known that some
> >> hardcoded deps were not yet in cvs and not ready to be build? People
> >> will run into issues that way when using yum and thus the it's just a
> >> totally stupid thing to do in a stable branch (and even quite bad in the
> >> deel-branch, too).
> >> /me is getting more and more annoyed with all those broken deps and
> >> broken upgrade paths (some of them for months)...
> > It would be better to automate checks so that packages without 
> > dependencies dont get pushed out in the repositories. [...]
> 
> Sure, but that's easier said then implemented ;) Especially now that we
> might need to merge the Extras and Core push scripts...

Push scripts like we use currently would be the wrong place where to check
dependencies, anyway.

Checking all of Fedora Extras 3,4,5,6,devel against all of Fedora Core
plus Updates plus Legacy (i.e. what the current broken deps report does)
takes a lot of time. Around 45 minutes on the build master. That is
with cached metadata.

It would need to become a dedicated server process with a queue (possibly
a stack), since with every package which builds fine or which breaks
dependencies, respectively, there are reoccurring operations. Like putting
back in the "publish queue" any packages which have been withdrawn before
due to broken deps. Or recalculating the complete repository closure for
all pending packages to find out what set of packages is "good to go"
after another [possibly related] build job completed.

More important, post-build checks add another state to the tuple "failed,
needsign" which introduces interactivity and must give the package
maintainer a chance to influence the release process.

For instance, the tools for an upgraded suite of programs build fine and
without breaking any deps, but parts of the run-time components of the
upgraded suite break deps inside the repository. That would be a scenario
where a package maintainer would need to be able to block an entire group
of builds in order to not release only half of it.


Also keep in mind that every successfully built package is available to
all subsequent build jobs via the "needsign" queue. If such a package is
not released, trash in the needsign queue piles up when it is not fixed
soon. And the two reports about breakage in Extras and Core show examples,
where fixes are missing for a long time.