Bug#1007717: Draft resolution for "Native source package format with non-native version"
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 -- Sean Whitton signature.asc Description: PGP signature
Bug#1007717: attempt to summarize current state of this bug
> "Matthew" == Matthew Vernon writes: Matthew> Hi, I thought it might be useful to try and summarize where Matthew> we are with this bug, which hasn't see much recent activity Matthew> (not least as there's a TC meeting later...). I read your summary and agree it is accurate. Thank you. signature.asc Description: PGP signature
Bug#1007717: attempt to summarize current state of this bug
Hi, I thought it might be useful to try and summarize where we are with this bug, which hasn't see much recent activity (not least as there's a TC meeting later...). * Questions asked of the TC The Committee was invited to issue advice on a number of points: I - continued use of 1.0 native format 1) declare that there is nothing with with a package with a native format but a non-native version number 2) request the dpkg maintainer relax the restriction of 3.0 native that prevents using that format with a non-native version number 3) declare that the MBF on the topic shouldn't have been filed against packages where the change is more complicated than simply change the source format II - continued use of 1.0-with-diff 4) declare that there are circumstances where use of 1.0-with-diff is the best tradeoff between different considerations 5) declare that the MBF on this topic shouldn't have been filed against packages that are 1.0-with-diff (or at least not against all of them) During the following discussion, TC has also been invited to come up with policy on native packages and Debian revisions. * Package formats The TC have been told that: 1.0-without-diff is in some circumstances better than 3.0 (native), because dpkg prohibits use of 3.0 native with a non-native version number; were that restriction relaxed, 3.0 (native) could replace 1.0-native 1.0-with-diff has advantages over 3.0 (quilt) particularly with git-based workflows, because in 3.0 (quilt) the diff is included inside the source tree 3.0 (quilt) with single-debian-patch can represent some changes to the source tree that 1.0-with-diff cannot native format has the advantage over any quilt or diff format that it can represent some changes to a source tree that patch/diff cannot represent (e.g. changes to symlinks, which are changes you can make in git) I don't believe any of these statements has been challenged. * Discussion in the bug Lucas (who filed the MBFs) has stated that they do not intend to make them RC, nor reopen ones that the maintainers close. This may well make 3/5 relatively moot? The issue of preferred form for modification has been raised (source package in general, quilt stack, or VCS repo); Sam states that there is consensus both that git workflows are best practice (especially where upstream uses git), and that natives packages are sometimes an appropriate tool to use. There is a wide range of git workflows, which the occasional NMUer can avoid caring about by use of dgit(7). There was also discussion of whether 1.0 formats were "niche" - they represent 1.9% of packages in testing. Russ argues that we should allow both native and non-native packages (defined by whether there is a separate upstream release from the Debian package) to use single-tarball source formats (and that the name 3.0 (native) is a bit confusing here); Felix instead contends that "native" means instead that a package lacks a Debian patch, and we should stop defining native or otherwise in terms of version numbers. There was some further discussion of better terminology, but I don't think it went anywhere conclusive. Updates / corrections welcome :) HTH, Matthew
