Re: Add Debian revision number standards to policy?
Loïc Minier <lool+debian@via.ecp.fr> writes:
> On Mon, Nov 21, 2005, Goswin von Brederlow wrote:
>> Since common practice for NMU, binNMU and security versions are
>> flawed, as in they don't sort right with dpkg --compare-versions, I
>> would rather see a new scheme be made policy.
>> Currently versions sort the following way:
>> 1.2-3
>> 1.2-3sarge1
>> 1.2-3.0.1
>> 1.2-3.1
>
> That's one sample of versions: package, "security upload", binNMU, NMU,
> let me show you another one:
> 1.2-3
> 1.2-3.1
> 1.2-3.1sarge1
> 1.2-3.1sarge1.0.1
> ... where one could read versions for: package, NMU, "security upload"
> of the NMU, binNMU of that security upload.
What is your point?
In my example the binNMU done _BEFORE_ the security release sorts
_AFTER_ the security release. So updates will not get the fix.
In your example everything is sorted the way it is ment to.
> I believe one can compose and branch version stanzas as one prefers to,
> and Ubuntu can re-branch versions from any Debian version, and any
> version can be NMUed or binNMUed.
>
> I'd rather see something in the lines of:
> "1/ Package versions usually have no dots, except for NMUs and binNMUs."
> "2/ If you do a sourceful NMU of a package, the version should be of the
> form old-version.NMU-version except if old-version had a dot; in this
> case, you should increment the NMU part of the version and drop the
> rest"
>
> Also, I don't think security versions can easily be distinguished from
> a general "branching", so I'd prefer the functionality be described as
> such.
The problem is that binNMUs branch the binary but not the source and
the whole binNMU branch must sort lower than the next source update,
which is not the case for security updates.
> I suppose all of this would best be described by examples, and BNF
> rules or regular expressions.
MfG
Goswin
PS: 1.2-3.0.1 binNMU gets rejected by DAK now, only 1.2-3+b1 is
accepted.
Reply to: