[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: binary NMUs and version numbers

* Scott James Remnant (scott@netsplit.com) [041128 12:55]:
> To summarise the discussion so far:
> [...]

Thanks for your nice summarising.

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

AFAICS, it is already consensus that neither of these formats is the
ways to go.

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

I guess we have enough time for even doing the build epoch right before
release of sarge. And, frankly speaking, I think we should first do the
right decision, based on the technical facts, and than consider how we
can implement the best solution.

My personal feeling is different to yours: I prefer the build epoch
solution, because I consider it the cleaner solution, even if it
requires changes to some packages. However, even if you disagree and go
to the +b-solution, I would prefer that much to the current one, and so
I hope that we are able to finalize the decision soon.

Thanks for your effor.

   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Reply to: