wanna-build state changes by dinstall
Hi,
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.)
Changes to the same source package
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Source-Version: 1.2.3
Binary-Version: 1.2.2
WB-Version less than source-version
=> package goes to needs-build
(sending mail in case package is building)
Source-Version: 1.2.3
Binary-Version: 1.2.2
WB-Version equals source-version
=> nothing changed (stays in building, depwait, whatever)
Source-Version: 1.2.3
Binary-Version: 1.2.3
=> package goes to installed
Changes to other source packages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The new binary version(s) could resolve dep-waits of other packages.
(Question: Should we out-source this to edos? Shouldn't be too hard,
just using depwait--- instead of source--- for these "packages".)
Edos-checking
~~~~~~~~~~~~~
All packages in needs-build are checked via edos.
Incomplete / conflicting information
====================================
I think that was the easy part. The harder comes now:
1. Too new binaries / WB-version
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Source-Version: 1.2.3
Binary-Version: 1.2.4
=> we could either not touch the package at all, or just move it to
installed. I'd tend to the first one (at least for now), together with
an appropriate warning.
Same with Source-Version > Binary-Version, but WB-Version >
Source-Version.
2. Source/binary packages duplicates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In this case, I'd tend to only look at the new versions for "is it out
of date", and to all versions for edos / dep-waits.
3. Different binary versions / hijacked binaries
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
What to do if the packages coming from the same source package are
available with different versions? What to do if some are not
available from the right source package at all?
E.g. currently bash tells it builds (amongst other) bashdb, but the
bashdb binary package indicates that it comes from the source package
bashdb.
I would tend to say:
We only use binary packages that declare they come from the source
package we're looking at. If at least one binary package is current,
we declare the binary package to be installed (and dump "partial"
which we don't really use now anyways - if we ever need it we could
reintroduce it based on a cleaner description here).
4. Handling of the architecture line
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Currently we mostly dump the architecture line in favor of
Packages-arch-specific. We could declare an source-package to be
mostly non-existant on an architecture it doesn't declare itself to be
existant. What do you think of such an change? (Or just add an new
state, "unported"/"unsupported".) - This change could be done any time
later.
Other cases? Comments?
Andi
Reply to: