aboutsummaryrefslogtreecommitdiff
path: root/bpkg/system-package-manager-debian.cxx
diff options
context:
space:
mode:
Diffstat (limited to 'bpkg/system-package-manager-debian.cxx')
-rw-r--r--bpkg/system-package-manager-debian.cxx22
1 files changed, 13 insertions, 9 deletions
diff --git a/bpkg/system-package-manager-debian.cxx b/bpkg/system-package-manager-debian.cxx
index 1abfb84..f1c794d 100644
--- a/bpkg/system-package-manager-debian.cxx
+++ b/bpkg/system-package-manager-debian.cxx
@@ -1561,6 +1561,8 @@ namespace bpkg
// Map the version.
//
+ // NOTE: THE BELOW DESCRIPTION IS ALSO REPRODUCED IN THE BPKG MANUAL.
+ //
// To recap, a Debian package version has the following form:
//
// [<epoch>:]<upstream>[-<revision>]
@@ -1646,28 +1648,28 @@ namespace bpkg
// to revision. Note that this also means we will have to make the 0
// revision explicit. For example:
//
- // 1.2.3-0~ubuntu20.04
// 1.2.3-1~debian10
+ // 1.2.3-0~ubuntu20.04
//
// The next case to consider is when we have the upstream version
// (upstream-version manifest value). After some rumination it feels
- // correct to use it instead of the <epoch>-<upstream> components in the
+ // correct to use it in place of the <epoch>-<upstream> components in the
// above mapping (upstream version itself cannot have epoch). In other
// words, we will add the pre-release and revision components from the
// bpkg version. If this is not the desired semantics, then it can always
// be overrided with the distribution version.
//
- // Finally, we have the distribution version. The <epoch> and <upstream>
- // components are straightforward: they should be specified by the
- // distribution version as required. This leaves pre-release and
+ // Finally, we have the distribution version. The Debian <epoch> and
+ // <upstream> components are straightforward: they should be specified by
+ // the distribution version as required. This leaves pre-release and
// revision. It feels like in most cases we would want these copied over
// from the bpkg version automatically -- it's too tedious and error-
// prone to maintain them manually. However, we want the user to have the
// full override ability. So instead, if empty revision is specified, as
- // in 1.2.3-, then we automatically add bpkg revision. Similarly, if empty
- // pre-release is specified, as in 1.2.3~, then we add bpkg pre-release.
- // To add both automatically, we would specify 1.2.3~- (other combinations
- // are 1.2.3~b.1- and 1.2.3~-1).
+ // in 1.2.3-, then we automatically add the bpkg revision. Similarly, if
+ // empty pre-release is specified, as in 1.2.3~, then we add the bpkg
+ // pre-release. To add both automatically, we would specify 1.2.3~- (other
+ // combinations are 1.2.3~b.1- and 1.2.3~-1).
//
// Note also that per the Debian version specification, if upstream
// contains `:` and/or `-`, then epoch and/or revision must be specified
@@ -1857,6 +1859,8 @@ namespace bpkg
// fairly complex ones) tend to prefer dh and there is no reason for us to
// try to buck this trend.
//
+ // NOTE: THE BELOW DESCRIPTION IS ALSO REWORDED IN BPKG-PKG-BINDIST(1).
+ //
// So, to sum up, the plan is to produce debian/rules that uses the dh
// command sequencer and then invoke dpkg-buildpackage to produce the binary
// package from that. While this approach is normally used to build things