Re: wanna-build state changes by dinstall
* Andreas Barth (aba@not.so.argh.org) [100603 14:29]:
> I'm trying to write down which kind of state changes dinstall could
> influence. "needs-build" means any of its substates, i.e. needs-build,
> BD-Uninstallable. "building" means any of its substates, i.e.
> building, built, build-attempted. (The goal of this text is to make
> our handling more consistent - currently we parse Packages multiple
> times at different locations, and ignore some output of the first
> round in the second round.)
Another topic for that is: how do we handle *proposed-updates? (I'll
always refer to testing, and t-p-u, but of course this is valid for
all suites with p-u. And this is only about packages in testing,
because obviously a source package in t-p-u needs to be handled "the
same way" as in any other suite (except that we should make sure it
doesn't get built if the binary is already in testing but no longer in
t-p-u. Or does dak make sure this doesn't happen? Hm.))
There are quite a few packages that are technically spoken
out-of-date, but shouldn't be tried because they're broken / not for
that architecture but not in the P-a-s file, e.g. mongodb.
Also, it might happen that a package goes to testing which is
out-of-date. Also in that case we shouldn't try to build it in
testing.
On the other hand, we might want to schedule a binNMU in testing
whenever needed.
We have a couple of alternatives: One would be to set all the packages
from testing to "installed" in case they are, and delete all other
packages in testing. Or, perhaps better, but the not-installed ones in
some auto-not-for-us-state. Or just put all packages from testing into
auto-maybeinstalled - we usually don't need to touch them anyways.
What do you think?
Andi
Reply to: