Devuan deployment of britney2
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 

182 lines
8.6 KiB

  1. Solutions to common policy decisions
  2. ====================================
  3. .. contents::
  4. Britney complains about a fixed bug in the source suite (bug policy)
  5. --------------------------------------------------------------------
  6. All decisions about bugs are related to data set extracted
  7. from the bug tracker. If britney says that the new version
  8. introduces a bug, then it is because the data set from the bug
  9. tracker lists that bug for *a* version in the source suite,
  10. without it appearing for the version(s) in the target suite.
  11. Please note that these data sets do not include versions, so
  12. britney is unable to tell exactly which versions are affected.
  13. The only thing, it can tell, is what suite the bug affects.
  14. There is a number of common cases, where this is observed:
  15. * The metadata on the bug is wrong. A known example is the
  16. Debian BTS, where if a bug has a `fixed` version equal to
  17. a `found` version, the bug is considered unfixed.
  18. * The bug is fixed, but the old version is still around in
  19. the source suite. In this case, britney will generally
  20. also mention a "missing build" or "old binaries".
  21. If the metadata is wrong, the solution is to fix it in the bug
  22. tracker and wait until britney receives a new data set. In
  23. the other case, the recommendation is to see the sections on
  24. "missing builds" and "old binaries" below. As long as they
  25. are present, the package may be blocked by bugs in the older
  26. versions of the binaries.
  27. Britney complains about "missing builds"
  28. ----------------------------------------
  29. A "missing build" happens when britney detects that the binaries
  30. for a given architecture are missing or not up to date. This
  31. is detected by checking the "Packages" files in the archive, so
  32. britney has no knowledge of *why* the build is missing.
  33. Accordingly, this kind of issue is flagged as a "possibly permanent"
  34. issue.
  35. If the omission is deliberate (e.g. the new version no longer
  36. supports that architecture), then please have the old binaries
  37. for that architecture removed from the *source* suite. Once
  38. those are removed, britney will no longer see that as a problem.
  39. Otherwise, please check the build services for any issues with
  40. building or uploading the package to the archive.
  41. **Common misconceptions**: If the architecture is no longer
  42. supported, the removal of the old binaries should happen in
  43. the *source* suite (e.g. Debian unstable). However, many
  44. people mistakenly request a removal from the *target* suite
  45. (e.g. Debian testing). Unfortunately, this is not the proper
  46. solution (and, britney does not support architecture
  47. specific removals so it may be difficult to do anyhow).
  48. Britney complains about "old binaries"
  49. --------------------------------------
  50. Depending on the configuration of the britney instance, this may
  51. or may not be a blocker. If the distribution has chosen to enable
  52. the "ignore_cruft" option, this is merely a warning/note. That
  53. said, even in this mode it can block a package from migration.
  54. This appears when britney detects that there are older versions of
  55. the binary packages around, which was built by (an older version of)
  56. the same source package.
  57. This is common with distributions where their archive management
  58. software is capable of keeping old binaries as long as something
  59. depends on them (e.g. DAK as used by Debian). Therefore, the
  60. most common solution is to ensure all reverse dependencies are
  61. updated to use the new binaries and then have the old ones
  62. removed (the latter commonly known as "decrufting"). Technically,
  63. this is also solvable by "decrufting" without updating/rebuilding
  64. other packages. Though whether this is an acceptable practise
  65. depends on the distribution.
  66. Alternatively, if the distribution uses the "ignore_cruft" option,
  67. this (in itself) is not a blocker. However, it commonly triggers
  68. non-obvious issues:
  69. * If the bugs policy is enabled, an bug in the old binaries that
  70. is fixed in the new version will still be a blocker. Here, the
  71. best solution is to get rid of the old binaries.
  72. * Note: the bugs data is not versioned so britney cannot tell which
  73. versions the bug applies to. Just which suite they affect.
  74. * Even if the migration item is a valid candidate (i.e. all policy
  75. checked have passed), it may cause installability regressions as
  76. britney will also attempt to keep the old binaries around as long
  77. as they are used. The most often cause of this when the old
  78. binaries are not co-installable with the new ones.
  79. * Note: Britney generally only works with the highest version of a
  80. given binary. If you have libfoo1 depends on libfoo-data v1 and
  81. then libfoo2 depends on libfoo-data v2, then libfoo1 will become
  82. uninstallable as libfoo-data v2 will "shadow" libfoo-data v1.
  83. Britney complains about "Piuparts"
  84. ----------------------------------
  85. Britney can be configured to take the results of piuparts (package
  86. installation, upgrading and removal testing suite) into account. Currently this
  87. policy is only taking into account the piuparts result for installing and
  88. purging the package in the source suite and the target suite (so no upgrade
  89. test). As with the other policies, a regression means that the package passes
  90. in the target suite, but fails in the source suite. Unless this is a bug in
  91. piuparts, the package needs to be fixed first to install and purge cleanly in
  92. the non-interactive debconf state. An URL to the relevant piuparts results is
  93. provided in the excuses.
  94. Britney complains about "autopkgtest"
  95. -------------------------------------
  96. Maintainers can add autopkgtest test cases to their packages. Britney can be
  97. configured to request a test runner instance (in the case of Debian, this is
  98. debci) to run relevant tests. The idea is that a package that is a candidate
  99. for migration is updated in the target suite to its candidate version and that
  100. the autopkgtest case(s) of the package (if it has any) *and* those of all
  101. reverse dependencies are run. Regression in the results with respect to the
  102. current situation in the target suite can influence migration in the following
  103. ways, depending on britney's configuration:
  104. * migration is blocked
  105. * regression adds to the required time a package needs to be in the source
  106. suite before migration is considered (via the age policy). This time can
  107. then be used to investigate the situation and potentially block migration
  108. via other policies (e.g. the bug policy).
  109. Regression in the autopkgtest of the candidate package just needs to be fixed
  110. in the package itself. However, due to the addition of test cases from reverse
  111. dependencies, regression in this policy may come from a test case that the
  112. package does not control. If that is the case, the maintainers of the package
  113. and the maintainers of the regressing test case typically need to discuss and
  114. solve the issue together. The maintainers of the package have the knowledge of
  115. what changed, while the maintainers of the reverse dependency with the failing
  116. test case know what and how the test is actually testing. After all, a
  117. regression in a reverse dependency can come due to one of the following reasons
  118. (of course not complete):
  119. * new bug in the candidate package (fix the package)
  120. * bug in the test case that only gets triggered due to the update (fix the
  121. reverse dependency, but see below)
  122. * out-of-date reference date in the test case that captures a former bug in
  123. the candidate package (fix the reverse dependency, but see below)
  124. * deprecation of functionality that is used in the reverse dependency and/or
  125. its test case (discussion needed)
  126. Unfortunately sometimes a regression is only intermittent. Ideally this should
  127. be fixed, but it may be OK to just have the autopkgtest retried (how this is to
  128. be achieved depends on the setup that is being used).
  129. There are cases where it is required to have multiple packages migrate together
  130. to have the test cases pass, e.g. when there was a bug in a regressing test
  131. case of a reverse dependency and that got fixed. In that case the test cases
  132. need to be triggered with both packages from the source suite in the target
  133. suite (again, how this is done depends on the setup).
  134. If britney is configured to add time to the age policy in case of regression, a
  135. test case that hasn't been run (but ran successfully in the past) will also
  136. cause the penalty to be added. This is harmless, because once the results come
  137. in, the penalty will no longer be effective. Similarly, a missing build will
  138. also cause the (harmless) penalty.
  139. A failing test that has never succeeded in britney's memory will be treated as
  140. if the test case doesn't exist.
  141. On top of the penalties for regressions, britney can be configured to reward
  142. bounties for packages that have a successful test case.