On Thu, 2004-11-25 at 13:53 +0100, Andreas Barth wrote:
> there has been some casual discussion on IRC about version numbers for
> binary-only NMUs, and different ideas have been exchanged. I try to
> summarize the status, so that we can get to a decision.
>
To summarise the discussion so far:
Bug #62529.
The question is the format of version that dpkg will recognise as a
binary-only NMU, an upload that changes the binary version of the
package but not the source version.
The reason we want this is so dpkg can obtain the original source
version from the binary version and arrange matters such that both
${Source-Version} and the Source: header reflect this.
Using ‘wibble’ in the following example as the binary-only NMU
identifier, we want to achieve:
Source: foo (1.2-3)
Binary: foo
Version: 1.2-3wibble
Depends: foo-common (= 1.2-3)
This solves:
- archive and testing migration scripts identifying binary-only NMUs;
they simply need look at the Source header, rather than attempting
their own heuristics.
- binary-arch packages depending on a binary-all package; such as
multiarch libfoo-common-dev packages. The ${Source-Version} variable
would contain the original source version being recompiled, the
dependencies would match.
This does not solve:
- binary-all packages depending on a binary-arch package; this is a
rare occurrence, we could simply deprecate this.
The choice of format is important for its sorting properties:
a) it must sort higher than the previous version of the package;
1.2-3 << 1.2-3wibble
b) it must sort lower than the next version of the package, including
minor/NMU revisions;
1.2-3wibble << 1.2-4
1.2-3wibble << 1.2-3.1
c) it must sort lower than security and cdd uploads, though we have the
freedom to suggest a change of format for these;
1.2-3wibble << 1.2-3woody1
1.2-3wibble << 1.2-3ubuntu1
The formats suggested so far:
- 1.2-3.0.1 (bin-NMU of source), 1.2-3.2.1 (bin-NMU of NMU).
Current style; this clashes with many valid version numbers,
especially when used for native packages. It does not pass (c).
- 1.2-3b1
"Build #n" style; slight potential clash with valid version numbers,
but not a major one. Passes (c) if the string matches [^ab].
- 1.2-3+b1
"Plus build #n" style; this clearly identifies the fact that it's a
bin-NMU in all situations. It does not pass (c), however we can
alter the security and cdd upload format to +sec-woody1 (or any other
string matching +[^ab]).
- 1.2-3^1
"Build epoch" style; this would require changes to dpkg and APT's
versioning scheme, requiring a skipped-release use delay. ^ would
sort less than everything, including letters, so passes all 3.
My personal feeling currently gravitates towards the +b1 form, with
+sec-woody1 and +patch-ubuntu1 as possible security and cdd forms; I
don't think we have enough time to get the build epoch style into all
the required software and tested before sarge.
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
Attachment:
signature.asc
Description: This is a digitally signed message part