On 2008-03-16, Adam D. Barratt [EMAIL PROTECTED] wrote:
On Sun, 2008-03-16 at 03:47 -0700, Steve Langasek wrote:
The current binNMU numbering scheme was selected explicitly to allow
security uploads to sort later by numbering as
last_version+releaseserial; e.g., 1.2-5.1+etch1.
That makes
Gunnar Wolf [EMAIL PROTECTED] writes:
At some point in 2006, a serious flaw is addressed via a NMU, so
it sits at 1.0+sarge1. I still cannot be bothered to take a look at
the damn package. Time passes. In March 2008 it (again) shows it needs
to be taken care of, and you kindly prepare a new
Bas Wijnen wrote:
On Wed, Mar 19, 2008 at 11:37:07AM -0700, Russ Allbery wrote:
Bas Wijnen [EMAIL PROTECTED] writes:
We have other ways of tracking that information than the version, though.
Yes, and I don't really care, I just think going from +s1+nmu1 to +s2
seems to be doing things that
Luk Claes [EMAIL PROTECTED] writes:
Bas Wijnen wrote:
Yes, sorry. I forgot that those exist as well. :-)
Why are we bothering to make something up if everyone is using etchnr
etc?
1.0-1sarge1 1.0-1etch1. We don't have this problem currently because
1.0-1etch1 1.0-1lenny1, but we will
On Wed, Mar 19, 2008 at 07:54:46PM +0100, Luk Claes wrote:
Bas Wijnen wrote:
On Wed, Mar 19, 2008 at 11:37:07AM -0700, Russ Allbery wrote:
Bas Wijnen [EMAIL PROTECTED] writes:
We have other ways of tracking that information than the version, though.
Yes, and I don't really care, I
Russ Allbery dijo [Wed, Mar 19, 2008 at 12:05:53PM -0700]:
Yes, sorry. I forgot that those exist as well. :-)
Why are we bothering to make something up if everyone is using etchnr
etc?
1.0-1sarge1 1.0-1etch1. We don't have this problem currently because
1.0-1etch1 1.0-1lenny1, but
Gunnar Wolf [EMAIL PROTECTED] writes:
Russ Allbery dijo [Wed, Mar 19, 2008 at 12:05:53PM -0700]:
1.0-1sarge1 1.0-1etch1. We don't have this problem currently
because 1.0-1etch1 1.0-1lenny1, but we will again at some point in
the future, and it would be nice to resolve it once and for all.
On Sun, Mar 16, 2008 at 06:40:25PM +, Adam D. Barratt wrote:
On Sun, 2008-03-16 at 11:22 -0700, Russ Allbery wrote:
Adam D. Barratt [EMAIL PROTECTED] writes:
On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote:
[...]
Good idea. Even better, IMO, would be to use a system which is in
Bas Wijnen wrote:
On Sun, Mar 16, 2008 at 06:40:25PM +, Adam D. Barratt wrote:
On Sun, 2008-03-16 at 11:22 -0700, Russ Allbery wrote:
Adam D. Barratt [EMAIL PROTECTED] writes:
On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote:
[...]
Good idea. Even better, IMO, would be to use a
Bas Wijnen [EMAIL PROTECTED] writes:
Ok, that makes sense. However, with +nmu1, there still is the problem
of how to name security uploads. With +s1, they sort after +nmu1, which
I think is wrong.
There's no reason why we have to stick to one suffix. +s1+nmu1 for an NMU
after a security
[Adding bug #437392 to Cc, which deals with this issue for normal NMUs,
because I'm making a suggestion about them.]
On Sat, Mar 15, 2008 at 11:52:55PM +, Adam D. Barratt wrote:
devscripts 2.10.19 (soon to be uploaded) will modify the behaviour of
debchange --nmu to version an NMU of a
* Adam D. Barratt:
Currently, debchange will produce a version number of X-0.1 in such
cases which suffers from the problem described above. It has been
suggested that either one of +s1 / +sec1 / +security1 or release1
should be used to avoid the issue.
For stable and oldstable, we need
On Sunday 16 March 2008 00:52, Adam D. Barratt wrote:
We're aware that the Developers Reference specifies that the latter
format should be used, but it is problematic as -0.1 sorts before +b1
and, as such, the NMU will not supersede any previous binNMUs of the
same package version.
Whilst
On Sun, Mar 16, 2008 at 11:36:20AM +0100, Thijs Kinkhorst wrote:
On Sunday 16 March 2008 00:52, Adam D. Barratt wrote:
We're aware that the Developers Reference specifies that the latter
format should be used, but it is problematic as -0.1 sorts before +b1
and, as such, the NMU will not
On Sunday 16 March 2008 11:47, Steve Langasek wrote:
The current binNMU numbering scheme was selected explicitly to allow
security uploads to sort later by numbering as
last_version+releaseserial; e.g., 1.2-5.1+etch1.
Ah, I wasn't aware of that (and no-one seems to be using it currently). The
On Sun, Mar 16, 2008 at 03:47:56AM -0700, Steve Langasek wrote:
The current binNMU numbering scheme was selected explicitly to allow
security uploads to sort later by numbering as
last_version+releaseserial; e.g., 1.2-5.1+etch1.
This could also lead to a problem in very rare cases: If a
On Sun, 16 Mar 2008, Thijs Kinkhorst wrote:
On Sunday 16 March 2008 00:52, Adam D. Barratt wrote:
We're aware that the Developers Reference specifies that the latter
format should be used, but it is problematic as -0.1 sorts before +b1
and, as such, the NMU will not supersede any previous
On Sun, 2008-03-16 at 03:47 -0700, Steve Langasek wrote:
The current binNMU numbering scheme was selected explicitly to allow
security uploads to sort later by numbering as
last_version+releaseserial; e.g., 1.2-5.1+etch1.
That makes sense, although doesn't seem to match current practice. Was
Le Sun, Mar 16, 2008 at 12:10:13PM +0100, Bas Wijnen a écrit :
This could also lead to a problem in very rare cases: If a program has
the same version in stable and testing, and gets a security update, then
they both get a similar version. For the example, say 1.2-5.1+sarge1 in
stable and
On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote:
[Adding bug #437392 to Cc, which deals with this issue for normal
NMUs, because I'm making a suggestion about them.]
On Sat, Mar 15, 2008 at 11:52:55PM +, Adam D. Barratt wrote:
devscripts 2.10.19 (soon to be uploaded) will modify the
On Sun, Mar 16, 2008 at 08:23:43PM +0900, Charles Plessy wrote:
Le Sun, Mar 16, 2008 at 12:10:13PM +0100, Bas Wijnen a écrit :
This could also lead to a problem in very rare cases: If a program has
the same version in stable and testing, and gets a security update, then
they both get a
Adam D. Barratt [EMAIL PROTECTED] writes:
On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote:
[Adding bug #437392 to Cc, which deals with this issue for normal
NMUs, because I'm making a suggestion about them.]
On Sat, Mar 15, 2008 at 11:52:55PM +, Adam D. Barratt wrote:
devscripts
On Sun, 2008-03-16 at 11:22 -0700, Russ Allbery wrote:
Adam D. Barratt [EMAIL PROTECTED] writes:
On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote:
[...]
Good idea. Even better, IMO, would be to use a system which is in
line with non-native packages. How about this rule:
[using X.1]
Bas Wijnen wrote:
This does break versions which go from 1 to 1.1 to 1.2 to 2 to 2.1, etc,
but we're talking about native packages, which means we can expect
upstream not to be so crazy.
People do this all the time, for completly sane reasons.
--
see shy jo
signature.asc
Description:
[nutshell version for those who can't be bothered to read the full
mail :-) - what version number should a security upload of a native
package have]
Hi,
devscripts 2.10.19 (soon to be uploaded) will modify the behaviour of
debchange --nmu to version an NMU of a native package as X+nmu1 rather
25 matches
Mail list logo
