* Andreas Barth ([email protected]) [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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
