Re: wanna-build state changes by dinstall
* Andreas Barth (aba@not.so.argh.org) [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
Reply to: