Version numbering for security uploads of native packages - Debian

This is a discussion on Version numbering for security uploads of native packages - Debian ; 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 writes: > > >> We have other ways ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 25 of 25

Thread: Version numbering for security uploads of native packages

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

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


    Except that 1.1 is a MU unlike a security upload. One can expect that a
    decision was made about including (or not) the NMU in the next MU
    upload.

    --
    James
    GPG Key: 1024D/61326D40 2003-09-02 James Vega

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

    iEYEARECAAYFAkfhZxIACgkQDb3UpmEybUAxhACcDwv6wa1qjl enqhkOdsT7bY1v
    5EMAoJeTZGQ67GHP5ryThGktYRURVDy4
    =YVmL
    -----END PGP SIGNATURE-----


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

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


    Umh... With release cycles close to 18 months, this would mean tha,
    being I a bad and lazy maintainer, I didn't touch my native package
    for over three years. Say, version 1.0 was released with Sarge, in
    2005. 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 NMU, properly
    labeling it 1.0+etch1.

    It gets rejected, as it is a lower version.

    I have not touched the package for three years at last. Tell me, don't
    you think this should trigger some QA alarms? At very least, I'd agree
    with you uploading 1.~1+etch1. That way, when I'm finally done with my
    Precious 1.1 release, I can still properly upload it without any fuzz.

    Greetings,

    --
    Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244
    PGP key 1024D/8BB527AF 2001-10-23
    Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF


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

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

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


    > Umh... With release cycles close to 18 months, this would mean tha,
    > being I a bad and lazy maintainer, I didn't touch my native package for
    > over three years. Say, version 1.0 was released with Sarge, in 2005. 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 NMU, properly labeling it
    > 1.0+etch1.


    > It gets rejected, as it is a lower version.


    > I have not touched the package for three years at last. Tell me, don't
    > you think this should trigger some QA alarms? At very least, I'd agree
    > with you uploading 1.~1+etch1. That way, when I'm finally done with my
    > Precious 1.1 release, I can still properly upload it without any fuzz.


    Sure, and this is why we haven't seen much problem with this. I think I
    remember only seeing one of these between sarge and etch. But there was
    one, and since it's a simple problem to solve by picking a somewhat more
    predictable versioning scheme, it seems worth the minor effort.

    There are packages where the only updates between two releases are for
    minor things like standards-version or Vcs and Homepage headers that
    aren't horribly vital. They're rare, but they do exist. I've not
    uploaded a new version of sident since the etch release, for example, and
    while I plan to do so when I have time to clean up some minor stuff,
    nothing would be fundamentally broken about it if I didn't. It's less
    likely that this would happen in combination with non-maintainer or
    non-unstable updates that would provoke this versioning, but I can see it
    happening.

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

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

    Gunnar Wolf 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 NMU, properly
    > labeling it 1.0+etch1.
    >
    > It gets rejected, as it is a lower version.


    how about having it uploaded as 1.0+sarge1+etch1. looks funny, but
    actually follows the policy that says to 'append' +etch1 to such uploads.

    --
    Gruesse/greetings,
    Reinhard Tartler, KeyID 945348A4


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

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

    On 2008-03-16, Adam D. Barratt 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 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).


    We'll adapt our practise to use +etchX for security updates.

    Cheers,
    Moritz


    --
    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 2 of 2 FirstFirst 1 2