Jesse Keating wrote:
On Saturday 11 November 2006 13:26, Nicolas Mailhot wrote:
Not if we block only the broken parts. You know, instead of using
testers to shame maintainers in fixing broken deps, have the buildsys do
it, and only expose sane trees to users (with the "broken" packagesets
being held where the buildsys can find them till they're complete)
Thats quite the complexity to try spinning the tree, find broken deps, drop
out packages, try again, rather, rinse repeat.
No, it's a do-while loop.
If you start doing this from a working tree, you always have yesterday's
known-good state to start from. On any given day, some subset of your
packages will have changed EVR. Start with a compose that includes all
updated packages, and walk it for broken deps. Define depgraph
subtrees, rooted at and containing only components in a broken dep line
(both sides) that have been updated since yesterday. Prune them from
the candidate set for compose, and try again.
Brief gedanken analysis tells me this is roughly O(n log m) on worst
case behaviour, where one is the number of subtrees and the other is the
number of updated packages. I suspect in practice we'll see a typical
running time of 2.
This does mean there will be a set of packages in a new limbo state,
where they're built and published but not yet in a compose. Those
packages simply go into the candidate set again in tomorrow's compose.
Also the "both sides" part above might be aggressive, if we had done
that for the rawhide leading to FC6 then the kernel would never have
been updated because gnbd was always broken. Tough. Fix it, either by
excluding broken crap from the compose, or - shock - fixing the broken
packages.
(Jesse, I suspect the model you're thinking of it "oh crap, the tree has
broken deps, we can't publish _anything_". Which is wrong. You publish
the bits that are at least guaranteed by RPM requirements to install. I
mean, you want that for the updates stream for formal releases anyway,
where 'yum update' should _never_ fail, and I suspect right now the
releng team is doing that verification by hand. Trust the computer.
Let it do the boring work.)
Look, rawhide is just a work in progress, a snapshot of what happened the day
before. We can't aways have a completely stable tree. Trying for that is
the road to insanity.
Look, the kernel is just a work in progress, a snapshot of what happened
the day before. We can't always have something that compiles. Trying
for that is the road to insanity.
Let's play spot the fallacy! Hint: only one sentence was wrong.
Standard practice for rapid development environments is to require
working daily builds. For a distribution, an installable package set is
the definition of working.
- ajax
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
