Differences between revisions 21 and 32 (spanning 11 versions)
Revision 21 as of 2009-03-16 03:36:16
Size: 4648
Editor: anonymous
Comment: converted to 1.6 markup
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.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 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 for official architectures (except hurd-i386) ask on the [[http://lists.debian.org/debian-release/|debian-release mailing list]]. For kfreebsd-i386, kfreebsd-amd64 and hurd-i386, ask ${arch}@debian-ports.org .

Please read http://release.debian.org/wanna-build.txt for details on how a binNMU request should look like.
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 24: Line 22:
 * sources that build a single binary only (!arch=all) are always binNMU safe (internal dependencies should be concerned)
Line 28: 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~)}}}
Line 67: Line 65:

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