Version numbering for security uploads of native packages - Debian

This is a discussion on Version numbering for security uploads of native packages - Debian ; [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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 25

Thread: Version numbering for security uploads of native packages

  1. Version numbering for security uploads of native packages

    [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
    than the current X-0.1.

    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 looking at this change, the question arose of what format
    security uploads of native packages should use, both in general and
    specifically when debchange's --security option is used.

    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.

    The main difficulty with the latter from the point-of-view of adding
    support to debchange is that there's no easy way of mapping a changelog
    distribution (e.g. "stable") to a release name, particularly as both
    stable and oldstable updates may have "stable" as the last distribution
    to which the package was uploaded.

    After some discussion amongst the team on IRC we decided we'd be
    happiest following either a request from the security team or a
    consensus view (or as close to a consensus as -devel ever gets :-).

    Cheers,

    Adam


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Re: Version numbering for security uploads of native packages

    [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 +0000, 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 native package as X+nmu1 rather
    > than the current X-0.1.


    Good idea. Even better, IMO, would be to use a system which is in line
    with non-native packages. How about this rule:

    - An NMU will add an extra item to the version number, which starts
    counting at 1.
    - When a new upstream version of a non-native package is uploaded, the
    debian revision is set to 0, and the extra item is added to that.

    This means that non-native NMUs will get the same versions as they
    always did, while native packages go from "1.8" to "1.8.1", for example.
    For native packages, it's impossible to package a new upstream version,
    because there is no upstream.

    IMO this solution is slightly better than +nmu1, because it makes
    versions of native and non-native packages more uniformly mangled.
    However, any solution is better than no solution. :-)

    > Whilst looking at this change, the question arose of what format
    > security uploads of native packages should use, both in general and
    > specifically when debchange's --security option is used.
    >
    > 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.
    >
    > The main difficulty with the latter from the point-of-view of adding
    > support to debchange is that there's no easy way of mapping a changelog
    > distribution (e.g. "stable") to a release name, particularly as both
    > stable and oldstable updates may have "stable" as the last distribution
    > to which the package was uploaded.


    So the problem is that debchange is unable to know the version should be
    "stable"? Or is the problem that versions may collide when oldstable
    has a security update, and stable needs one as well? That doesn't make
    sense, because the version will have increased in unstable (by then
    stable) at the time the oldstable (at that time stable) update was made.

    I'm a bit confused by the problem.

    However, I do see a problem with +s1 if +nmu1 is used: +s1 sorts after
    +nmu1. This means that this versioning can no longer be used if an NMU
    is needed after a security update. In particular, suppose:
    - The package version is 1.3 in all distributions.
    - A security issue is found.
    - 1.3+s1 is uploaded to stable and testing.
    - The maintainer isn't available, and 1.3+nmu1 is uploaded to unstable.
    - Some time passes, and the package is about to migrate to testing.
    - Migration fails, because 1.3+nmu1 << 1.3+s1.

    This problem does not occur if 1.3.1 would be used for the normal NMU
    (to unstable).

    > After some discussion amongst the team on IRC we decided we'd be
    > happiest following either a request from the security team or a
    > consensus view (or as close to a consensus as -devel ever gets :-).


    I think using the rules I proposed above for normal NMUs, and +s
    for security NMUs would be best. However, I might misunderstand the
    problem.

    Thanks,
    Bas

    --
    I encourage people to send encrypted e-mail (see http://www.gnupg.org).
    If you have problems reading my e-mail, use a better reader.
    Please send the central message of e-mails as plain text
    in the message body, not as HTML and definitely not as MS Word.
    Please do not use the MS Word format for attachments either.
    For more information, see http://pcbcn10.phys.rug.nl/e-mail.html

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFH3NUQFShl+2J8z5URAod4AKCAVlEDy4VciASqzSpSaP BArPo+hgCeMuCg
    l0/r0vO/eNVwQIfkQbuRwWE=
    =/hdZ
    -----END PGP SIGNATURE-----


  3. Re: Version numbering for security uploads of native packages

    * 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 the process further
    down cannot be automated currently, so this doesn't help that much
    anyway. That's why I'm not inclined to put too much effert into this
    discussion. 8-/


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Re: Version numbering for security uploads of native packages

    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 looking at this change, the question arose of what format
    > security uploads of native packages should use, both in general and
    > specifically when debchange's --security option is used.


    There may not be a good solution since MU's, NMU's and security uploads can
    currently be interleaved in any particular order, so it seems hard to make a
    scheme that would work reliably.

    Occasionally there are problems with an upload being lower than a binNMU.
    binNMU's are problematic in this regard as they are often done without
    maintainer notification, and if you fetch the source package there's also no
    trace of them, both making it very easy to overlook. That would prompt me
    that reducing these problems may be sought in finding a better binNMU
    numbering scheme, one that sorts only just above the last sourceful upload
    but is very likely to be smaller than any time of new sourceful upload (mu,
    nmu or security) after it.

    I'm not yet sure what a good number would be there, but it seems the best
    place to tackle this problem.


    Thijs

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iQEVAwUAR9z4Jmz0hbPcukPfAQIcEggAoaHFYix3ojIk1j3lnE U3u+L95DI9pdW+
    TDjQPeEQlk3BkQehsk5KsVxnzVhWNU0AHrGD/d55KHPtMFds5Oh9UT5CaDsnGTiM
    yUsh5xZQZUCSoWtEPrta9Z/whWV2VPifdlzBPwkvzvL/mIVyfQMrTDsNmsJwT7O4
    7EFmZl3glwRfpzCBZE7drC1eT3Z2UdSsvKAztHoWZeNdG+OwXo OGWKOSQscL1XeR
    PVB+4fNgEfV5vF0IZlqCVoul6uynf9cydpf19UVVxAV61lStqw XZNtPbsC2Tjn0i
    2Qj0dY5QmruxYLEDOjjgekiBvZAiy8FwB/uvQ5sdxpWtHxvbKO+4JQ==
    =8ggl
    -----END PGP SIGNATURE-----


  5. Re: Version numbering for security uploads of native packages

    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 supersede any previous binNMUs of the
    > > same package version.


    > > Whilst looking at this change, the question arose of what format
    > > security uploads of native packages should use, both in general and
    > > specifically when debchange's --security option is used.


    > There may not be a good solution since MU's, NMU's and security uploads can
    > currently be interleaved in any particular order, so it seems hard to make a
    > scheme that would work reliably.


    > Occasionally there are problems with an upload being lower than a binNMU.
    > binNMU's are problematic in this regard as they are often done without
    > maintainer notification, and if you fetch the source package there's also no
    > trace of them, both making it very easy to overlook. That would prompt me
    > that reducing these problems may be sought in finding a better binNMU
    > numbering scheme, one that sorts only just above the last sourceful upload
    > but is very likely to be smaller than any time of new sourceful upload (mu,
    > nmu or security) after it.


    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.

    --
    Steve Langasek Give me a lever long enough and a Free OS
    Debian Developer to set it on, and I can move the world.
    Ubuntu Developer http://www.debian.org/
    slangasek@ubuntu.com vorlon@debian.org


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. Re: Version numbering for security uploads of native packages

    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 that they can't choose a release codename which starts
    with "a"? :-)


    Thijs

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iQEVAwUAR9z8+Gz0hbPcukPfAQKoZAf/Yddq7yPUZedUI8dmGzadQOegzdUD1IAT
    0N05gCth9dkXDhKoGuaW0FDHZ84S5VYioMeTU5XZD665FE087k W+afR5YtvCfoQ+
    eis0m8Zr3VV7i0BDIusd5hXj22eV6TfPdCj40oMgRE0hckjKtD QePdZqVZibwmDY
    tcce7XrEsimGarYqapjBzPvEDt2mqOWs62khsqAgp+FuvE83yR zqXU301AYXSkqd
    uK3N9rBJeFwsuiNd0U4230mNb7xVHU3nyy6KWSzNjrw5BA3hwB 4eKr/nVh9nG7OC
    7hTVMcrVwMGc4MkAQHNSEUUxC7NgZeX4qNejroqTThF0PF42BH X7Vw==
    =6A+x
    -----END PGP SIGNATURE-----


  7. Re: Version numbering for security uploads of native packages

    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 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 1.2-5.1+etch1 in testing. Now the version in testing is
    lower than that in stable, because "etch" << "sarge" (which is why I
    didn't use current names, since "lenny" is, by chance, >> "etch"). If
    this happens close to a release, and there is no new unstable
    (non-security-versioned) upload migrating to testing, this means users
    will end up with the oldstable version of the package (which may contain
    dependencies on wrong library versions, for example).

    This may never be a problem in reality, but it is a real bug in the
    numbering scheme, AFAICS.

    Thanks,
    Bas

    --
    I encourage people to send encrypted e-mail (see http://www.gnupg.org).
    If you have problems reading my e-mail, use a better reader.
    Please send the central message of e-mails as plain text
    in the message body, not as HTML and definitely not as MS Word.
    Please do not use the MS Word format for attachments either.
    For more information, see http://pcbcn10.phys.rug.nl/e-mail.html

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFH3QAVFShl+2J8z5URAsMvAJ0Xc/OsZjkeiuaMoQ345Fol93Z6LwCcDjAF
    kBzRg6+V5lWOVPitctbzicI=
    =EzCv
    -----END PGP SIGNATURE-----


  8. Re: Version numbering for security uploads of native packages

    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 binNMUs of the
    > > same package version.
    > >
    > > Whilst looking at this change, the question arose of what format
    > > security uploads of native packages should use, both in general and
    > > specifically when debchange's --security option is used.

    >
    > There may not be a good solution since MU's, NMU's and security uploads can
    > currently be interleaved in any particular order, so it seems hard to make a
    > scheme that would work reliably.


    It's possible, you just have to put the increment number before the
    "type" of upload:
    - +c0.nmu (non maintainer upload)
    - +c1.sec (security upload)
    - +c2.su (stable update)

    Unfortunately "+0.nmu" sorts before "+b1" so I had to put "+c0.nmu" so
    that binnmu sort lower. And "c" could mean "change" or "external change".

    Cheers,
    --
    Raphaël Hertzog

    Le best-seller français mis à jour pour Debian Etch :
    http://www.ouaza.com/livre/admin-debian/


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  9. Re: Version numbering for security uploads of native packages

    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 as to where NMUs of native packages should sort?
    (I realise that they're the only case that doesn't automagically dtrt
    with respect to the numbering scheme).

    Adam


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  10. Re: Version numbering for security uploads of native packages

    "Adam D. Barratt" 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 +0000, 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 native package as X+nmu1
    >> > rather than the current X-0.1.

    >>
    >> 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]
    >> IMO this solution is slightly better than +nmu1, because it makes
    >> versions of native and non-native packages more uniformly mangled.
    >> However, any solution is better than no solution. :-)

    >
    > That does seem the most logical suggestion thus far.


    I dislike this approach because it makes it impossible for tools like
    Lintian to recognize NMUs of native packages and perform other
    NMU-specific checks (such as making sure an appropriate changelog entry is
    present). There's no way of knowing whether a native package with a
    version number of 1.2.1 is an NMU or not.

    I like the +nmuN approach.

    --
    Russ Allbery (rra@debian.org)


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  11. Re: Version numbering for security uploads of native packages

    On Sun, 2008-03-16 at 11:22 -0700, Russ Allbery wrote:
    > "Adam D. Barratt" 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]
    > >> IMO this solution is slightly better than +nmu1, because it makes
    > >> versions of native and non-native packages more uniformly mangled.
    > >> However, any solution is better than no solution. :-)

    > >
    > > That does seem the most logical suggestion thus far.

    >
    > I dislike this approach because it makes it impossible for tools like
    > Lintian to recognize NMUs of native packages and perform other
    > NMU-specific checks (such as making sure an appropriate changelog entry is
    > present). There's no way of knowing whether a native package with a
    > version number of 1.2.1 is an NMU or not.


    Indeed. Luk already pointed out on irc that this is the (or at least a)
    reason .1 wasn't suggested by DevRef.

    > I like the +nmuN approach.


    devscripts 2.10.19 including +nmuN was uploaded earlier this evening.

    Adam


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  12. Re: Version numbering for security uploads of native packages

    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

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFH3bfwd8HHehbQuO8RAotQAJ0R2GNvYnyQ0KPOELNMOd ZxcKtyLACdGutz
    ExumSWBJ0E/ZJIxX6zPYK/A=
    =Tb/d
    -----END PGP SIGNATURE-----


  13. Re: Version numbering for security uploads of native packages

    On Sun, Mar 16, 2008 at 06:40:25PM +0000, Adam D. Barratt wrote:
    > On Sun, 2008-03-16 at 11:22 -0700, Russ Allbery wrote:
    > > "Adam D. Barratt" 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]
    > > >> IMO this solution is slightly better than +nmu1, because it makes
    > > >> versions of native and non-native packages more uniformly mangled.
    > > >> However, any solution is better than no solution. :-)
    > > >
    > > > That does seem the most logical suggestion thus far.

    > >
    > > I dislike this approach because it makes it impossible for tools like
    > > Lintian to recognize NMUs of native packages and perform other
    > > NMU-specific checks (such as making sure an appropriate changelog entryis
    > > present). There's no way of knowing whether a native package with a
    > > version number of 1.2.1 is an NMU or not.

    >
    > Indeed. Luk already pointed out on irc that this is the (or at least a)
    > reason .1 wasn't suggested by DevRef.


    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 to stable and testing anyway, so the
    +etch1 and similar version extensions are used. Do we want to solve the
    bug that they can have incorrect order? They should at least start with
    +X, where X is >> 'b' and << 'n', if they want to sort correctly with
    respect to binNMUs and source NMUs.

    > > I like the +nmuN approach.

    >
    > devscripts 2.10.19 including +nmuN was uploaded earlier this evening.


    Good. That fixes all problems except the security versions[1].
    Obviously a solution would be to add +debian., where
    should be anything that sorts correctly, such as the current
    stable version with "testing" added if the upload is to testing. This
    does perhaps result in versions which are longer than anyone would want,
    though (like 1.7.5+nmu3+debian3.1testing.1).

    Turning "debian" into "deb" and "testing" into "+" would make it
    better "1.7.5+nmu3+deb3.1+.1" is comparable in length to the current
    "1.7.5+nmu3+lenny1"

    Thanks,
    Bas

    [1] I'm working on a proposal to reformulate the devref section on NMUs.
    Since there seems to be consensus about using +nmuX, I'll include it
    in the proposal. If you don't agree that there is consensus, please
    say so. :-)

    --
    I encourage people to send encrypted e-mail (see http://www.gnupg.org).
    If you have problems reading my e-mail, use a better reader.
    Please send the central message of e-mails as plain text
    in the message body, not as HTML and definitely not as MS Word.
    Please do not use the MS Word format for attachments either.
    For more information, see http://pcbcn10.phys.rug.nl/e-mail.html

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFH3ireFShl+2J8z5URAmYTAJ9AKzg3TV/kuTrlF4MOkeh0J2huwQCgnyYP
    beXWeVJJhYEy7OjrrTS7b00=
    =U0r2
    -----END PGP SIGNATURE-----


  14. Re: Version numbering for security uploads of native packages

    Bas Wijnen wrote:
    > On Sun, Mar 16, 2008 at 06:40:25PM +0000, Adam D. Barratt wrote:
    >> On Sun, 2008-03-16 at 11:22 -0700, Russ Allbery wrote:
    >>> "Adam D. Barratt" 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]
    >>>>> IMO this solution is slightly better than +nmu1, because it makes
    >>>>> versions of native and non-native packages more uniformly mangled.
    >>>>> However, any solution is better than no solution. :-)
    >>>> That does seem the most logical suggestion thus far.
    >>> I dislike this approach because it makes it impossible for tools like
    >>> Lintian to recognize NMUs of native packages and perform other
    >>> NMU-specific checks (such as making sure an appropriate changelog entry is
    >>> present). There's no way of knowing whether a native package with a
    >>> version number of 1.2.1 is an NMU or not.

    >> Indeed. Luk already pointed out on irc that this is the (or at least a)
    >> reason .1 wasn't suggested by DevRef.

    >
    > 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 to stable and testing anyway, so the
    > +etch1 and similar version extensions are used. Do we want to solve the
    > bug that they can have incorrect order? They should at least start with
    > +X, where X is >> 'b' and << 'n', if they want to sort correctly with
    > respect to binNMUs and source NMUs.


    I did not see any comments about Raphael's proposition (that seems better
    to me):

    Raphael Hertzog wrote:
    > On Sun, 16 Mar 2008, Thijs Kinkhorst wrote:
    >> There may not be a good solution since MU's, NMU's and security uploads can
    >> currently be interleaved in any particular order, so it seems hard to make a
    >> scheme that would work reliably.

    >
    > It's possible, you just have to put the increment number before the
    > "type" of upload:
    > - +c0.nmu (non maintainer upload)
    > - +c1.sec (security upload)
    > - +c2.su (stable update)
    >
    > Unfortunately "+0.nmu" sorts before "+b1" so I had to put "+c0.nmu" so
    > that binnmu sort lower. And "c" could mean "change" or "external change".


    Best regards,
    Vincent

    --
    Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org
    GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
    Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package
    APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  15. Re: Version numbering for security uploads of native packages

    Bas Wijnen 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 upload is ugly but functional, and the next maintainer
    release would reset all the suffixes anyway. Likewise with appending
    another +bN for a binary NMU. As near as I can tell, since you would
    never base an NMU or security update on a binary NMU, the worst case is
    +s1+nmu1+b1, which isn't really that horrible.

    > Turning "debian" into "deb" and "testing" into "+" would make it better
    > "1.7.5+nmu3+deb3.1+.1" is comparable in length to the current
    > "1.7.5+nmu3+lenny1"


    If you go this route, please make it +deb31, not +deb3.1. The extra dot
    is historically special and indicates a binNMU.

    --
    Russ Allbery (rra@debian.org)


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  16. Re: Version numbering for security uploads of native packages

    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 to stable and testing anyway, so the
    > > +etch1 and similar version extensions are used. Do we want to solve the
    > > bug that they can have incorrect order? They should at least start with
    > > +X, where X is >> 'b' and << 'n', if they want to sort correctly with
    > > respect to binNMUs and source NMUs.

    >
    > I did not see any comments about Raphael's proposition (that seems better
    > to me):
    >
    > Raphael Hertzog wrote:
    > > It's possible, you just have to put the increment number before the
    > > "type" of upload:
    > > - +c0.nmu (non maintainer upload)
    > > - +c1.sec (security upload)
    > > - +c2.su (stable update)
    > >
    > > Unfortunately "+0.nmu" sorts before "+b1" so I had to put "+c0.nmu" so
    > > that binnmu sort lower. And "c" could mean "change" or "external change".


    I don't really like the c, but it also isn't really needed, as Russ
    pointed out:

    On Mon, Mar 17, 2008 at 10:26:44AM -0700, Russ Allbery wrote:
    > There's no reason why we have to stick to one suffix. +s1+nmu1 for an NMU
    > after a security upload is ugly but functional, and the next maintainer
    > release would reset all the suffixes anyway. Likewise with appending
    > another +bN for a binary NMU. As near as I can tell, since you would
    > never base an NMU or security update on a binary NMU, the worst case is
    > +s1+nmu1+b1, which isn't really that horrible.


    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 prefer the longer versions in this case. When a package gets too many
    security and other non-maintainer uploads, it should probably be
    orphaned or co-maintianed anyway (since there's appearantly a lot to do,
    and the maintainer isn't doing it).

    > > Turning "debian" into "deb" and "testing" into "+" would make it better
    > > "1.7.5+nmu3+deb3.1+.1" is comparable in length to the current
    > > "1.7.5+nmu3+lenny1"

    >
    > If you go this route, please make it +deb31, not +deb3.1. The extra dot
    > is historically special and indicates a binNMU.


    Hmm, the second dot probably has the same meaning then. So we should go
    for +deb31[+]_1 or something? To make it clear again:

    +deb is a fixed part which means this is a security upload
    31 is the current (at time of upload) stable release
    + means this is an upload to testing, skipping it means to stable
    _ is a fixed part to separate the 31 and the 1
    1 is a counter to allow more security uploads following this one.

    And once again the problem that is to be solved by this: When testing
    and stable are at the same version, and both get a security upload, the
    version in testing must not be lower than that in stable.

    Thanks,
    Bas

    --
    I encourage people to send encrypted e-mail (see http://www.gnupg.org).
    If you have problems reading my e-mail, use a better reader.
    Please send the central message of e-mails as plain text
    in the message body, not as HTML and definitely not as MS Word.
    Please do not use the MS Word format for attachments either.
    For more information, see http://pcbcn10.phys.rug.nl/e-mail.html

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFH4PhfFShl+2J8z5URApKbAJ9NhWhLBXRa9J/PG3ZtUg4gRmq8AQCeNsq2
    rg5PBmkUhwQd1UezCt5nnkw=
    =3fn1
    -----END PGP SIGNATURE-----


  17. Re: Version numbering for security uploads of native packages

    Bas Wijnen 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
    > security and other non-maintainer uploads, it should probably be
    > orphaned or co-maintianed anyway (since there's appearantly a lot to do,
    > and the maintainer isn't doing it).


    We have other ways of tracking that information than the version, though.

    > Hmm, the second dot probably has the same meaning then.


    This only matters when appended to a Debian revision; for native packages,
    it doesn't matter. So ignore me unless we're talking about using the same
    convention for both native and non-native packages. (Having three periods
    in the Debian revision is the old marker of a binNMU and various things
    may still trigger off that.)

    > So we should go for +deb31[+]_1 or something? To make it clear again:
    >
    > +deb is a fixed part which means this is a security upload


    Or any other stable upload, yes? We're not currently distinguishing
    between security uploads and maintainer uploads for the etch/sarge/etc.
    versions.

    > 31 is the current (at time of upload) stable release
    > + means this is an upload to testing, skipping it means to stable


    You wouldn't need the presence/absence thing of the + if you used a higher
    version number for the testing security update. I'd be inclined to say
    that we just always add 1 to the minor version of the last stable version
    when making a testing security upload until the actual version number for
    the next release has been picked. So in other words, use +deb40 for etch
    and +deb41 for lenny until a version number has been picked, under the
    assumption that the choices are 4.1 or 5.0 and either way 41 has the right
    version ordering properties. (Now, of course, people could start using
    +deb50 if they wanted to.)

    --
    Russ Allbery (rra@debian.org)


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  18. Re: Version numbering for security uploads of native packages

    On Wed, Mar 19, 2008 at 11:37:07AM -0700, Russ Allbery wrote:
    > Bas Wijnen 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
    > > security and other non-maintainer uploads, it should probably be
    > > orphaned or co-maintianed anyway (since there's appearantly a lot to do,
    > > and the maintainer isn't doing it).

    >
    > 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 it doesn't (revert the NMU).

    > > Hmm, the second dot probably has the same meaning then.

    >
    > This only matters when appended to a Debian revision; for native packages,
    > it doesn't matter. So ignore me unless we're talking about using the same
    > convention for both native and non-native packages.


    I was assuming to use the same convention indeed.

    > > So we should go for +deb31[+]_1 or something? To make it clear again:
    > >
    > > +deb is a fixed part which means this is a security upload

    >
    > Or any other stable upload, yes?


    Yes, sorry. I forgot that those exist as well. :-)

    > > 31 is the current (at time of upload) stable release
    > > + means this is an upload to testing, skipping it means to stable

    >
    > You wouldn't need the presence/absence thing of the + if you used a higher
    > version number for the testing security update. I'd be inclined to say
    > that we just always add 1 to the minor version of the last stable version
    > when making a testing security upload until the actual version number for
    > the next release has been picked.


    Sounds good to me as well.

    Thanks,
    Bas

    --
    I encourage people to send encrypted e-mail (see http://www.gnupg.org).
    If you have problems reading my e-mail, use a better reader.
    Please send the central message of e-mails as plain text
    in the message body, not as HTML and definitely not as MS Word.
    Please do not use the MS Word format for attachments either.
    For more information, see http://pcbcn10.phys.rug.nl/e-mail.html

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFH4WDUFShl+2J8z5URAqLuAJ9RnRMtiXtnyp62rlCifx qjynW08ACgiGx+
    0YEQcB+yL1YeEXUxxpCmd68=
    =i4iS
    -----END PGP SIGNATURE-----


  19. Re: Version numbering for security uploads of native packages

    Bas Wijnen wrote:
    > On Wed, Mar 19, 2008 at 11:37:07AM -0700, Russ Allbery wrote:
    >> Bas Wijnen 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 it doesn't (revert the NMU).


    Strange reasoning as 1.0-0.1 followed by 1.1 is also not reverting an
    NMU perse...

    >>> So we should go for +deb31[+]_1 or something? To make it clear again:
    >>>
    >>> +deb is a fixed part which means this is a security upload

    >> Or any other stable upload, yes?

    >
    > Yes, sorry. I forgot that those exist as well. :-)


    Why are we bothering to make something up if everyone is using etch etc?

    Cheers

    Luk


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  20. Re: Version numbering for security uploads of native packages

    Luk Claes 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 will again at some point in the future,
    and it would be nice to resolve it once and for all. Using something
    based on the Debian release version has the advantage that the version
    always increases from release to release. The code names bounce all over
    the place in version sorting space.

    And the original problem that sparked this thread is that devscripts is
    now using 1.0+nmu1 for NMUs of native packages and we're trying to figure
    out what version number should be used for security and/or stable uploads
    of native packages so that they sort properly. It would be nice if we
    could use the same convention for both native and non-native packages.

    --
    Russ Allbery (rra@debian.org)


    --
    To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread
Page 1 of 2 1 2 LastLast