On 10/05/22 at 17:29 -0700, Sean Whitton wrote: > Hello, > > At today's ctte meeting we considered whether we can start a vote on > this, but two committee members were missing, and someone else at the > meeting reported that they hadn't yet been able to spend enough time > thinking through the issue to be ready to vote. > > We came up with the following plan. Below I've drafted a ballot. Once > each of those three individuals has let me know that they've had a > chance to catch up, I'll start a vote. The hope is that this can happen > well in advance of our next meeting. So, ctte members, if I don't > already know that you're caught up, please write to me once you are. > > ~~~~~ > > DRAFT > > Using its powers under constitution 6.1.5, the Technical Committee > issues the following advice: > > 1. It is not a bug of any severity for a package with a non-native > version number to use a native source package format. > > 2. Thus, we think that dpkg shouldn't issue warnings, or otherwise > complain, when a non-native version number is used w/ 3.0 (native). > > 3. We suggest that the wontfix tag on #737634 be reconsidered. > > 4. We believe that there are indeed circumstances in which > 1.0-with-diff is the best choice for a particular source package, > including, but not limited to, git-first packaging workflows. > > 5. We decline to comment on the recent source package format MBF. > > Option A -- issue items 1--5 > > Option B -- issue items 1, 2, 3 and 5, but not 4 > > Option N -- none of the above. > > END DRAFT
Hi, If it was possible to use 3.0 (native) with non-native revisions, would there be remaining circumstances where 1.0-with-diff is the best choice? If not, maybe the fact that this is the blocking issue should be made explicit in (4)? That would be a way to state: "either dpkg maints refuses to support 3.0 (native) with non-native revs, and 1.0-with-diff must not be considered deprecated; or dpkg maints supports it, and it might be possible to deprecate 1.0". Lucas