Differences between revisions 3 and 4
Revision 3 as of 2006-09-26 02:25:39
Size: 1316
Editor: KevinMcCarty
Comment: fix typo, add another example, mention deprecation of ${Source-Version}
Revision 4 as of 2006-09-26 02:43:47
Size: 3849
Editor: KevinMcCarty
Comment: Merge in information from NonMaintainerUpload page which belongs better here
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
See also: NonMaintainerUpload See also:
 * NonMaintainerUpload
 * [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]
Line 6: Line 8:
== What are binNMUs? == = What are binNMUs? =
Line 8: Line 10:
A '''binNMU''' is a binary-only non-maintainer upload. In this case the {{{arch: any}}} packages are rebuild, but the {{{arch: all}}} packages are not. This is necessary for cases, where a simple rebuild (without any changes to the package) will fix a serious error, such as a library transition ([http://lists.debian.org/debian-release/2006/09/msg00003.html example]) or a misconfiguration on the maintainer's machine ([http://lists.debian.org/debian-release/2006/09/msg00297.html example]). 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 ([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 10: Line 12:
== How to make packages binNMU safe? == 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 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.)
Line 12: Line 14:
 * do ''not'' use the ${Source-Version} variable; this has been deprecated! = Where to request a binNMU? =

To request a binNMU ask for it on the [http://lists.debian.org/debian-release/ debian-release mailing list].

= How to make packages binNMU safe? =

== Executive summary ==

 * do ''not'' use the {{{${Source-Version}}}} variable; this has been deprecated!
Line 17: Line 27:
   * however, if only a minimum version is needed, one may use for instance {{{Depends: foo-binary (>= ${source:Version})}}}
Line 18: Line 29:
== Where to request a binNMU? == == Example ==
Line 20: Line 31:
To request a binNMU ask for it on the [http://lists.debian.org/debian-release/ debian-release mailing list]. For example, sometimes a package refers to the version of the source package in package relationship definitions:

{{{
 Source: foo
 
 Package: foo-bin
 Suggests: foo-doc (= ${Source-version})
 Architecture: any
 
 Package: foo-doc
 Architecture: all
}}}

The first upload creates the following versions:

 * Source package: ''foo 1.0-1''
 * Architecture specific package: ''foo-bin 1.0-1 (Suggests: foo-doc 1.0-1)''
 * Architecture independant package: ''foo-doc 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 (Suggests: foo-doc 1.0-1+b1)''
 * Architecture independant package: ''foo-doc 1.0-1''

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 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 (Suggests: foo-doc 1.0-1)''
 * Architecture independant package: ''foo-doc 1.0-1''

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 ([http://lists.debian.org/debian-release/2006/09/msg00003.html example]) or a misconfiguration on the package maintainer's machine ([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.

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 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.)

Where to request a binNMU?

To request a binNMU ask for it on the [http://lists.debian.org/debian-release/ debian-release mailing list].

How to make packages binNMU safe?

Executive summary

  • do not use the ${Source-Version} variable; this has been deprecated!

  • versioned dependency on dpkg-dev (>= 1.13.19)

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

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

  • 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})

Example

For example, sometimes a package refers to the version of the source package in package relationship definitions:

 Source: foo
 
 Package: foo-bin
 Suggests: foo-doc (= ${Source-version})
 Architecture: any
 
 Package: foo-doc
 Architecture: all

The first upload creates the following versions:

  • Source package: foo 1.0-1

  • Architecture specific package: foo-bin 1.0-1 (Suggests: foo-doc 1.0-1)

  • Architecture independant package: foo-doc 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 (Suggests: foo-doc 1.0-1+b1)

  • Architecture independant package: foo-doc 1.0-1

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 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 (Suggests: foo-doc 1.0-1)

  • Architecture independant package: foo-doc 1.0-1