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
>> +; e.g., 1.2-5.1+etch1.
>
> That makes sense, although do
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
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 a
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 etch
> > etc?
>
> 1.0-1sarge1 >> 1.0-1etch1. We don't have this problem currently because
> 1.0-1etch1 << 1.0-1
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 re
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 etch
> etc?
1.0-1sarge1 >> 1.0-1etch1. We don't have this problem currently because
1.0-1etch1 << 1.0-1lenny1, but we
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 th
On Wed, Mar 19, 2008 at 11:37:07AM -0700, Russ Allbery wrote:
> Bas Wijnen <[EMAIL PROTECTED]> writes:
>
> > You can base security uploads on NMUs, so I think you could get
> > +s1+nmu1+s1+nmu1, etc. Or should it go from +s1 to +s1+nmu1 to +s2 to
> > +s2+nmu1?
>
> I was assuming the latter.
>
>
Bas Wijnen <[EMAIL PROTECTED]> writes:
> You can base security uploads on NMUs, so I think you could get
> +s1+nmu1+s1+nmu1, etc. Or should it go from +s1 to +s1+nmu1 to +s2 to
> +s2+nmu1?
I was assuming the latter.
> I prefer the longer versions in this case. When a package gets too many
> se
On Mon, Mar 17, 2008 at 04:46:54PM +0100, Vincent Danjean wrote:
> Bas Wijnen wrote:
> > 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.
> >
> > But we're talking about uploads
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 securit
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, wou
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 syste
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: Di
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:
> >
"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:
>>
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
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 modif
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 a
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
> +; e.g., 1.2-5.1+etch1.
That makes sense, although doesn't seem to match current practice. Was
any consideration given
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 prev
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
> +; e.g., 1.2-5.1+etch1.
This could also lead to a problem in very rare cases: If a program has
the same version
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
> +; e.g., 1.2-5.1+etch1.
Ah, I wasn't aware of that (and no-one seems to be using it currently). The
release managers know
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 n
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.
>
> Whil
* 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 1
> should be used to avoid the issue.
For stable and oldstable, we need 1. But
[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 n
[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
t
28 matches
Mail list logo
