On 15.05.2012 19:56, Niels Thykier wrote:
In doop_source britney has the following if-statement (indentation
reduced):
"""
# if the binary already exists (built from another source)
if binary in binaries[parch][0]:
[...]
else:
# if the binary was previously built by a different
# source package in testing, all of the reverse
# dependencies of the old binary are affected.
# reverse dependencies built from this source can be
# ignored as their reverse trees are already handled
# by this function
# XXX: and the reverse conflict tree?
[...]
"""
The comments are slightly confusing on which branch is the "built
from
other source"-case, but most likely it is the "else" branch. From
this
I would expect that the majority of the "runs" will pass through the
other
branch... but it is actually not the case.
The comments could certainly do with some improvement, but I'm not
actually sure anything else is broken.
Ignoring the special case of single binary removals, doop_source
essentially does
1) Remove any binaries built by the version of the package currently in
testing
2) Remove the old source package
3) Add binaries built by the new version
4) Add the new source package
The code fragment above forms part of step 3. We've already removed the
binary packages previously built by the testing version of the source
package we're migrating in step 1. As a result, if the binary package
we're considering is already in testing when we hit step 3 then it is
currently being built by a different source package which is still in
testing - i.e. the new version of the source package is "taking over"
the binary package. In that case, we remove the record of the binary
package built by the other source package and mark the reverse
dependencies of /that/ binary package as affected.
The "else" branch checks whether the binary package used to be built by
a different source package which was removed earlier in the same run
(either entirely or by being superseded by a new version which dropped
the binary package). In this case, the RDEPENDS element of the binary
package we're attempting to add will reflect the reverse-dependencies of
the package currently in unstable. However, it may be the case that for
instance testing's version of bar depends on the binary package, but
that dependency has since been dropped in unstable. When we migrate the
new binary, we need to ensure that the reverse-dependencies of the
existing testing package (i.e. the one we removed earlier in the run)
are still installable; see commit 709ea952 where the branch was
originally introduced to solve a problem we'd had with a migration with
such a dropped dependency in unstable leading to britney allowing the
migration even though it introduced new breakage. In hindsight, the
comment could have been much less confusing.
Hope that helps
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
