Differences between revisions 8 and 32 (spanning 24 versions)
Revision 8 as of 2006-11-05 11:21:43
Size: 4630
Editor: ?SteinarGunderson
Comment: Fix the architecture list -- it's space-separated, not comma-separated.
Revision 32 as of 2019-08-16 13:17:58
Size: 4816
Editor: JensReyer
Comment: use source:Version instead of source:Upstream-Version for arch:all to arch:any
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
 * [http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-porter-guidelines the Debian Developer's Reference, §5.10.2.1 Recompilation or binary-only NMU]  * [[http://www.debian.org/doc/developers-reference/pkgs.html#porter-guidelines|the Debian Developer's Reference, §Recompilation or binary-only NMU]]
Line 10: Line 10:
A '''binNMU''' is a binary-only non-maintainer upload. This is necessary when the build for a specific architecture failed, or produced buggy packages, due to a problem in the build environment itself (not due to an error in the package source). Such problems include library transitions ([http://lists.debian.org/debian-release/2006/09/msg00003.html example]) or a misconfiguration on the package maintainer's machine used for preparing uploads ([http://lists.debian.org/debian-release/2006/09/msg00297.html example]). In a binNMU, the {{{arch: any}}} packages are rebuilt, but the {{{arch: all}}} packages are not. A '''binNMU''' is a binary-only non-maintainer upload. This is necessary when the build for a specific architecture failed, or produced buggy packages, due to a problem in the build environment itself (not due to an error in the package source). Such problems include library transitions ([[http://lists.debian.org/debian-release/2006/09/msg00003.html|example]]) or a misconfiguration on the package maintainer's machine used for preparing uploads ([[http://lists.debian.org/debian-release/2006/09/msg00297.html|example]]). In a binNMU, the {{{arch: any}}} packages are rebuilt, but the {{{arch: all}}} packages are not.
Line 12: Line 12:
Each of the {{{arch: any}}} packages receives a new version number which is the old version number with the suffix ''+b'' appended plus a version number for the binNMU (e.g. version '''2.3.4-3''' will become '''2.3.4-3+b1'''). The binNMU version is incremented independently on each architecture ([http://lists.debian.org/debian-release/2006/10/msg00044.html example]). The only file in the source package which is modified by the binNMU is {{{debian/changelog}}}, which gets a new entry for the new version. (Historically, binNMU version numbers were created by bumping (or creating, if it did not already exist) the third-level number in the Debian revision, for instance 2.3.4-3 would instead have become 2.3.4-3.0.1. This numbering convention is no longer used.) Each of the {{{arch: any}}} packages receives a new version number which is the old version number with the suffix ''+b'' appended plus a version number for the binNMU (e.g. version '''2.3.4-3''' will become '''2.3.4-3+b1'''). The binNMU version is incremented independently on each architecture ([[http://lists.debian.org/debian-release/2006/10/msg00044.html|example]]). The only file in the source package which is modified by the binNMU is {{{debian/changelog}}}, which gets a new entry for the new version. (Historically, binNMU version numbers were created by bumping (or creating, if it did not already exist) the third-level number in the Debian revision, for instance 2.3.4-3 would instead have become 2.3.4-3.0.1. This numbering convention is no longer used.) Please note, binNMUs don't need to be acknowledged in your source changelog afterwards, whereas [[NonMaintainerUpload|NMUs]] typically are.
Line 16: Line 16:
To request a binNMU ask for it on the [http://lists.debian.org/debian-release/ debian-release mailing list].

If you want to be kind to the RMs, you could use the following format in your e-mail, for each (package, binNMU tuple number):

{{{
[package]_[source-version], [reason], [binNMU number], [list of archs]
}}}

for instance:

{{{
package_0.1-1, Rebuild against newer libc6 (Closes: #123456), 1, i386 amd64 s390
}}}

However, if you do not know the exact binNMU number (and you're too lazy to look it up using rmadison), just ask the regular way and someone else will construct the proper line for you.
Please read [[https://release.debian.org/wanna-build.html|the documentation]] for details on how a binNMU request should look like and where to send the request to.
Line 36: Line 22:
 * sources that build a single binary only (!arch=all) are always binNMU safe (internal dependencies should be concerned)
Line 38: Line 25:
 * versioned {{{Build-Depends}}} on {{{dpkg-dev (>= 1.13.19)}}}
Line 41: Line 27:
 * no way for a safe dependency between an {{{arch: all}}} to an {{{arch: any}}} package using these variables
   * however, if only a minimum version is needed, one may use for instance {{{Depends: foo-binary (>= ${source:Version})}}}
 * declaring dependency between an {{{arch:all}}} to an {{{arch:any}}} package: {{{Depends: foo (>= ${source:Version}), foo (<< ${source:Version}.1~)}}}

'''Note:''' The versioned {{{Build-Depends}}} on {{{dpkg-dev (>= 1.13.19)}}} is '''not''' needed anymore, since Etch, Lenny and Sid all have the necessary version.
Line 46: Line 33:
For example, sometimes a package refers to the version of the source package in package relationship definitions: For example, sometimes a package refers to the version of the source package in package relationship definitions. Consider a source package that still uses the deprecated {{{${Source-Version}}}} variable:
Line 52: Line 39:
 Suggests: foo-doc (= ${Source-version})  Depends: foo-common (= ${Source-Version})
Line 55: Line 42:
 Package: foo-doc  Package: foo-common
Line 62: Line 49:
 * Architecture specific package: ''foo-bin 1.0-1 (Suggests: foo-doc 1.0-1)''
 * Architecture independant package: ''foo-doc 1.0-1''
 * Architecture specific package: ''foo-bin 1.0-1 (Depends: foo-common 1.0-1)''
 * Architecture independent package: ''foo-common 1.0-1''
Line 65: Line 52:
Now, suppose the foo-bin package is binNMU uploaded for an architecture. The {{{${Source-version}}}} variable is retrieved from debian/changelog, so after the binNMU the archive will contain the following versions: Now, suppose the foo-bin package is binNMU uploaded for an architecture. The {{{${Source-Version}}}} variable is retrieved from debian/changelog, so after the binNMU the archive will contain the following versions:
Line 68: Line 55:
 * Architecture specific package: ''foo-bin 1.0-1+b1 (Suggests: foo-doc 1.0-1+b1)''
 * Architecture independant package: ''foo-doc 1.0-1''
 * Architecture specific package: ''foo-bin 1.0-1+b1 (Depends: foo-common 1.0-1+b1)''
 * Architecture independent package: ''foo-common 1.0-1''
Line 71: Line 58:
The foo-doc package needs no new upload, because it was properly created before! However, there is no version 1.0-1+b1 of foo-doc, so the dependencies are messed up. The foo-common package needs no new upload, because it was properly created before! However, there is no version 1.0-1+b1 of foo-common, so the dependencies are now broken, and foo-bin is uninstallable on the architecture where foo was binNMU'ed.
Line 73: Line 60:
The solution is to use {{{${source:Version}}}} instead of {{{${Source-version}}}}. This variable is also retrieved from the latest entry in the changelog, but any ''+b'' suffix is discarded. So, the following packages are created: The solution is to use {{{${source:Version}}}} instead of {{{${Source-Version}}}}. This variable is also retrieved from the latest entry in the changelog, but any ''+b'' suffix is discarded. So, the following packages are created:
Line 76: Line 63:
 * Architecture specific package: ''foo-bin 1.0-1+b1 (Suggests: foo-doc 1.0-1)''
 * Architecture independant package: ''foo-doc 1.0-1''
 * Architecture specific package: ''foo-bin 1.0-1+b1 (Depends: foo-common 1.0-1)''
 * Architecture independent package: ''foo-common 1.0-1''

Please, see an little explanation about {{{${binary:Version}}}} at http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-intradeps.
----
CategoryPackaging

The info in this thread could be the starting point for this page: http://lists.debian.org/debian-mentors/2006/09/msg00223.html

See also:

What are binNMUs?

A binNMU is a binary-only non-maintainer upload. This is necessary when the build for a specific architecture failed, or produced buggy packages, due to a problem in the build environment itself (not due to an error in the package source). Such problems include library transitions (example) or a misconfiguration on the package maintainer's machine used for preparing uploads (example). In a binNMU, the arch: any packages are rebuilt, but the arch: all packages are not.

Each of the arch: any packages receives a new version number which is the old version number with the suffix +b appended plus a version number for the binNMU (e.g. version 2.3.4-3 will become 2.3.4-3+b1). The binNMU version is incremented independently on each architecture (example). The only file in the source package which is modified by the binNMU is debian/changelog, which gets a new entry for the new version. (Historically, binNMU version numbers were created by bumping (or creating, if it did not already exist) the third-level number in the Debian revision, for instance 2.3.4-3 would instead have become 2.3.4-3.0.1. This numbering convention is no longer used.) Please note, binNMUs don't need to be acknowledged in your source changelog afterwards, whereas NMUs typically are.

Where to request a binNMU?

Please read the documentation for details on how a binNMU request should look like and where to send the request to.

How to make packages binNMU safe?

Executive summary

  • sources that build a single binary only (!arch=all) are always binNMU safe (internal dependencies should be concerned)
  • only a potential problem for source packages that generate multiple binary packages
  • do not use the ${Source-Version} variable; this has been deprecated!

  • declaring dependency between 2 arch: any packages: ${binary:Version}

  • declaring dependency between an arch: any to an arch: all package: ${source:Version}

  • declaring dependency between an arch:all to an arch:any package: Depends: foo (>= ${source:Version}), foo (<< ${source:Version}.1~)

Note: The versioned Build-Depends on dpkg-dev (>= 1.13.19) is not needed anymore, since Etch, Lenny and Sid all have the necessary version.

Example

For example, sometimes a package refers to the version of the source package in package relationship definitions. Consider a source package that still uses the deprecated ${Source-Version} variable:

 Source: foo
 
 Package: foo-bin
 Depends: foo-common (= ${Source-Version})
 Architecture: any
 
 Package: foo-common
 Architecture: all

The first upload creates the following versions:

  • Source package: foo 1.0-1

  • Architecture specific package: foo-bin 1.0-1 (Depends: foo-common 1.0-1)

  • Architecture independent package: foo-common 1.0-1

Now, suppose the foo-bin package is binNMU uploaded for an architecture. The ${Source-Version} variable is retrieved from debian/changelog, so after the binNMU the archive will contain the following versions:

  • Source package: foo 1.0-1

  • Architecture specific package: foo-bin 1.0-1+b1 (Depends: foo-common 1.0-1+b1)

  • Architecture independent package: foo-common 1.0-1

The foo-common package needs no new upload, because it was properly created before! However, there is no version 1.0-1+b1 of foo-common, so the dependencies are now broken, and foo-bin is uninstallable on the architecture where foo was binNMU'ed.

The solution is to use ${source:Version} instead of ${Source-Version}. This variable is also retrieved from the latest entry in the changelog, but any +b suffix is discarded. So, the following packages are created:

  • Source package: foo 1.0-1

  • Architecture specific package: foo-bin 1.0-1+b1 (Depends: foo-common 1.0-1)

  • Architecture independent package: foo-common 1.0-1

Please, see an little explanation about ${binary:Version} at http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-intradeps.


CategoryPackaging