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

Re: DEP1: Non Maintainer Uploads (final call for review)



Hi,

Sorry for breaking the thread and chiming in late, I was until recently not 
aware of this thread and not subscribed to debian-project. I hope my comments 
can still be considered.

>    The version must be the version of the last upload, plus +nmuX,

>    This special versioning is needed to avoid stealing one of the
>    package maintainer's version numbers, which might disrupt their
>    work.

The past weeks I had several encounters with the situation that a maintainer 
completely overlooked and NMU and uploaded a newer version without 
acknowledging the previous NMU, thereby reintroducing the problem the NMU 
addressed. This happened to active maintainers.

I was wondering why we version NMU's differently from MU's. If they used the 
same scheme, in these cases the subsequent upload from the MU would have been 
rejected. That would have flagged a problem for them and they had discovered 
the NMU they forgot to integrate. Of course it wouldn't help in any situation 
but it would have helped these.

I do not really buy the "stealing" argument since maintainers do not "own" 
version numbers. It indeed interferes with their work but it *needs* to. A 
completely ignored NMU has been rendered ineffective.

>    If you upload a package to testing or stable, you sometimes need
>    to "fork" the version number tree. This is the case for security
>    uploads, for example. For this, a version of the form +debXYuZ
>    should be used, where X is the current stable major release
>    number, and Y is the current minor release number for a stable
>    upload, or one higher than that for a testing upload. Z is a
>    counter starting at 1. For example, while Etch (Debian 4.0) is
>    stable, a security NMU to stable for a package at version 1.5-3
>    would have version 1.5-3+deb40u1, while a security NMU to Lenny
>    would get version 1.5-3+deb41u1. This is the case even when it
>    is already known that the next release will be a new major
>    version ; for instance, Lenny will be released as Debian 5.0.

I am not very happy with this paragraph. The proposed scheme is in my opinion 
hard to read, and it gets especially confusing when 40 means 4.1 and 41 means 
5.0.

We already have a scheme in the security team that prevents this numbering 
confusion, and that is to use release codenames. It makes it clear at a 
glance whether a package is intended for stable or testing, and the codenames 
do not change.

The current convention is to add +etch1 or +lenny1 respectively. This scheme 
works well. It would fail when we have a release name starting with "a", but 
that situation doesn't exist and can be easily prevented. The scheme was 
recently changed to cope better with binNMU's, and I'm not sure what the 
benefit would be to change it yet again within a few months. The problems we 
have, like today with postfix, are when maintainers use the old scheme which 
is indeed suboptimal.

I'm unclear on the reasons of changing the current system. It works, so why 
change it? I prefer to codify existing practice than the other way around in 
this case.


cheers,
Thijs

Attachment: pgpjMqrcStWXg.pgp
Description: PGP signature


Reply to: