(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
Attachment:
signature.asc
Description: Digital signature