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
Reply to: