* Andreas Barth ([email protected]) [100606 11:59]: > 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.
First, I intended to create a state "known", which is the maximum of installed and needs-build, i.e. for take, failed, attempted, ... it behaves like needs-build, for binNMU it behaves like installed, and it doesn't set packages from needs-build to known unless directed to do so. Which of course means we need to adjust a couple of things, and we need an way to specify "--needs-build". (Then I thought we could use use --binNMU 0 to say "needs-build". That is an ugly hack, but gave me the following thought.) The other alternative would be to just set the packages to "installed" with an appropriate note as "related" or so. We could always schedule a binNMU from there, even if the package hadn't been built yet. And we have all the infrastructure in place. The downside is that this is hackish, and "installed" doesn't mean "installed" but "we don't care". So, summarizing: Unless someone has an better idea (or thinks that's too hackish), I tend to implement the second later today. Also, on further thinking, it might be nice to be able to binNMU packages in experimental. So I would also like add the additional packages to experimental, but that could happen later. We should probably limit the binNMU-space, something like +b100 and upwards for experimental, and code that to wanna-build (at least for packages in the installed%related state). Andi -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
