Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads
On Wed, Aug 19 2009, Raphael Hertzog wrote:
> On Tue, 18 Aug 2009, Manoj Srivastava wrote:
>> Additionally,
>> § 5.6.21. `Files' mentions that the .dsc will contain a diff.gz if
>> applicable
>> § C.1.1. `dpkg-source' states that it creates a diff.gz if
>> appropriate, and looks at the diff.gz while extracting if
>> applicable.
>
> Heh, reading this remind me that policy should probably be updated to
> reflect the new source package formats... (diff.gz can also be
> debian.tar.<ext>, etc.)
I think appendix C is mostly stuff that is not normativce, and is
only around until it can be incorporated into dpkg documentation. If
you think all the material in that appendix is currently available in
dpkg, we can just drop appendix C from policy.
>
>> Given these, I read this as letting the tools rely on
>> the following invariants, even though these are not explicitly spelled
>> out in so many words in policy:
>>
>> 1) If there is a - in the version number, then the package is
>> non-native
>> a) the upstream version is the part of the string until the last
>> '-' in the version number
>> b) there is a .orig.tar.gz and
>> c) diff.gz referenced in the .dsc
>> 2) If there is no '-' in the version number, then the package is a
>> debian native package
>> a) there is no debian revision, all the version number is the
>> upstream version number
>> b) there is a tar.gz and no diff.gz in the .dsc file
> There's no such invariant although it's a recommended practice:
> http://lintian.debian.org/tags/native-package-with-dash-version.html
That is correct. (I thought that there would be other
references in dev-ref or policy, but if there are I missed them, but
you may add that if you have a '-' in the version number, debhelper
seems to think it should not be native)
This proposal is to take current best practice and move it into
policy, since standardization here would help tools and users
> And the type of file associated is going to be different once the archive
> accepts new source formats.
>
> Format: 1.0 accepts either .tar.gz or (.diff.gz + orig.tar.gz)
> Format: 3.0 (native) allows .tar.{gz,bz2,lzma}.
> Format: 3.0 (quilt) allows debian.tar.{gz,bz2,lzma} +
> orig.tar.{gz,bz2,lzma} + optionals orig-<foo>.tar.{gz,bz2,lzma}
>
> dpkg-source doesn't impose any restriction on the package's version
> when using any of those formats.
OK. I was not planning on adding the above to policy anyway,
just to express my understanding of the current state, but thanks for
pointing out that the above understanding fails to take into account
the new package format.
You are correct in that policy should not contain anything that
goes against the new package formats.
>> 1) dch --nmu adds +nmu1 for native packages
>> 2) +nmuX is already supported by devscripts and lintian.
>> 3) the developers reference also advocates adding +<codename>\d+. It
>> also advocates using exactly the same tar.gz file as already in the
>> archive.
>
> While I would like us to standardize on +nmuX for all NMU, there's no
> general consensus here. The developers-reference has changed again the
> recommendation to match the dch --nmu practice:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532945
> Now I believe that consistency here would be a win that is more important
> than the ugliness or aesthetic problem that some DD seem to have with this
> convention. I don't know if the discussion during the policy process can
> lead to agreement on this.
This could be a problem. I would prefer a succinct rule for the
tools to rely on (even if it will take a while). Do you think if
policy recommended \+nmu\d+ and lintian had a warning, this might
change? Or should policy leave it alone?
>> A corresponding name space can be carved out for security
>> uploads. Obviously a solution would be to add +debion>.<counter>, where
>> <version> should be anything that sorts correctly, such as the current
>> stable version with something added if the upload is to testing.
>> \+deb\d\d.\d+
>> \+debt\d\d.\d+ (testing only, sorts ahead of stable)
>>
>> where
>> 1.0.1 --old--> 1.0.1+etch1 --> 1.0.1+deb40
>> 1.0-1 --old--> 1.0.1+etch1 --> 1.0-1+deb40
>>
>> (sarge --> deb31, etch -->deb40, lenny --> deb50)
>
> We had this discussion in the threads that discussed DEP1 on -project.
> We did not reach a consensus (with the security team) here.
>
> Subthread starting here:
> http://lists.debian.org/debian-project/2008/08/msg00136.html(Thijs is part of the security team)
>
> But I also think that it would be nice to have a working long-term
> solution and I would be in favor of such a scheme. The main objection was
> that we do not know the next version in advance and the release team
> has changed this fact, we already know that squeeze will be 6.0 and it
> should stay the same in the future as the reasoning of this was to
> facilitate the work of documentation writers.
Wel, the testing security uploads also have their own namespace
in this proposal to address that objection:
"+" "debt" "<major minor of last release"
debt says this is uploaded to testing. So pacakges with a security
upload to Squeeze will have \+debt50 added, as opposed to Lenny which
has \+deb50 (notice the missing t). We can change debt to debtesting if
just the t is not enough to distinguish the name for humans.
Can a security team member say if this namespace would be
acceptable?
>> You can base security uploads on NMUs, so I think you could get
>> +deb50.1
>> +deb50.1+nmu1
>> +deb50.2
>> +deb50.2+nmu1
>
> Hum I understand +nmu1+deb50.1 for a security upload of a package whose
> last upload was an NMU, but I don't see in what occasions you would NMU a
> package in stable/testing (package in unstable don't have security
> uploads). And even if you did, I don't see why you keep the +deb50.1
> instead of simply replacing it with +nmu1.
Yes, it was late when I wrote that. We cancertainly come up with
a better progression example, if the rest of the proposal sounds good.
--
Drilling for oil is boring.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: