(Please keep debian-devel in the CC. This issue is a project-wide isssue.) Bart Martens wrote: > How do other tools this?
Other well-respected tools in debhelper's situation, such as? yada It introduces a completely nonstandard Upstream-Source field in debian/control which it takes to mean the package is not native. debstd Same as debhelper. cdbs Same as debhelper. Manoj's standardised rules files Same as debhelper. > > I can think > > of a few ways, but they're all fairly complicated and fragile. > > Maybe verifying the presence of an .orig.tar.gz ? Complicated, fragile, out of scope for debhelper, which does not deal with debian source packages after all, breaks once wig-n-pen is implemented. > > Policy is actually careful to set up the invarient that "-" anywhere in > > a version number means the package is not native. > > Policy states that if there is no "debian_revision" then hyphens "-" are > not allowed in the "upstream_version". > http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version > Policy also states that "native Debian packages" are "packages which > have been written especially for Debian". > http://www.debian.org/doc/debian-policy/ch-binary.html#s3.2.1 > > Policy does not explicitly state that the presence/absence of a > "debian_revision" or that the presence/absence of hyphen(s) "-" indicate > whether or not the package is a "native Debian package". <debian_revision> It is optional; if it isn't present then the <upstream_version> may not contain a hyphen. This format represents the case where a piece of software was written specifically to be turned into a Debian package, and so there is only one "debianisation" of it and therefore no revision indication is required. This strongly implies that debian native packages don't use debian_revision. > > I don't know why the > > developers reference choses to ignore that. > > Policy and developer's reference do not contradict explicitly on the > version numbering of an NMU of a native package. The developer's reference chose to ignore or change a longstanding practice of never using debian revision numbers in native packages. Changing this breaks software that has relied on this practice for ten or more years. Not just debhelper, but debstd and cdbs, and who knows what else. > Interesting idea, but it does not conform to current po^H^Hdeveloper's > reference, Please stop trying to conflate policy and the developer's reference. The developers reference is not something one conforms to, it is something one refers to. > and changing this now probably breaks existing software > depending on the current version numbering of NMU's of native packages. Well, I've identifes several more pieces of software that are broken by the syntax introduced by the developer's reference. Can you identify at least *1* that would be broken by not following it? Bear in mind that appending "0.0.0.1" or similar is a de-facto standard that is what most people did for many years when NMUing native packages. -- see shy jo
signature.asc
Description: Digital signature