我的书签
添加书签
移除书签5.14.4. Frequently asked questions
5.14.4.1. What are release-critical bugs, and how do they get counted?
All bugs of some higher severities are by default considered release-critical; currently, these are critical, grave and serious bugs.
Such bugs are presumed to have an impact on the chances that the package will be released with the stable release of Debian: in general, if a package has open release-critical bugs filed on it, it won’t get into testing, and consequently won’t be released in stable.
The unstable bug count comprises all release-critical bugs that are marked to apply to package/version combinations available in unstable for a release architecture. The testing bug count is defined analogously.
5.14.4.2. How could installing a package into testing possibly break other packages?
The structure of the distribution archives is such that they can only contain one version of a package; a package is defined by its name. So when the source package acmefoo is installed into testing, along with its binary packages acme-foo-bin, acme-bar-bin, libacme-foo1 and libacme-foo-dev, the old version is removed.
However, the old version may have provided a binary package with an old soname of a library, such as libacme-foo0. Removing the old acmefoo will remove libacme-foo0, which will break any packages that depend on it.
Evidently, this mainly affects packages that provide changing sets of binary packages in different versions (in turn, mainly libraries). However, it will also affect packages upon which versioned dependencies have been declared of the ==, <=, or << varieties.
When the set of binary packages provided by a source package changes in this way, all the packages that depended on the old binaries will have to be updated to depend on the new binaries instead. Because installing such a source package into testing breaks all the packages that depended on it in testing, some care has to be taken now: all the depending packages must be updated and ready to be installed themselves so that they won’t be broken, and, once everything is ready, manual intervention by the release manager or an assistant is normally required.
If you are having problems with complicated groups of packages like this, contact debian-devel@lists.debian.org or debian-release@lists.debian.org for help.
See the Debian Policy Manual for guidelines on what section a package belongs in.
In the past, such NMUs used the third-level number on the Debian part of the revision to denote their recompilation-only status; however, this syntax was ambiguous with native packages and did not allow proper ordering of recompile-only NMUs, source NMUs, and security NMUs on the same package, and has therefore been abandoned in favor of this new syntax.
ITS is shorthand for “Intend to Salvage”
Though, if a package still is in the in the upload queue and hasn’t been moved to Incoming yet, it can be removed. (see Uploading to ftp-master)
