Hi,
I re-read a bit on the policy definition of native vs. non-native
packages and it occurred to me that the written word of the policy seems
to be confusing to read at best.
The concept of a native package is introduced in chapter 4 "Source
packages" and the following definition is given:
"""
Debian **source** packages are classified as native or non-native.
A native source package is one that does not distinguish between Debian
packaging releases and upstream releases. A native source package
contains a single tar file of source material, and the versioning does
not have a Debian-specific component. Native packages are normally (but
not exclusively) used for software that has no independent existence
outside of Debian, such as software written specifically to be a Debian
package.
[... more stuff about non-native packages ...]
"""
I put emphasis here on "Debian **source** packages", which implies that
this definition do not apply to binary packages. I had a look in Chapter
3 "Binary packages" and it does mention "Native Debian packages" but
does not define the term.
I assume the term in chapter 3 is a forward reference to chapter 4
but it never explicitly states this. I feel it would aid the reader if
it did have a explicit forward reference if that is what it is.
Based on this assumption, I feel the full term should probably be
along the lines of "binary packages built from a (non-)native source
package". However, I admit that phrase is a bit obscene to use compared
to "N(on-n)ative Debian packages" as it is a full sentence on its own.
However, the shorter phrase used now may confuse readers into believing
that "native binary packages" are a thing, which they do not seem to be
according to chapter 4.
Assuming we agree so far, this has the consequences that:
* The basename of the installed changelog name ("changelog" vs.
"changelog.Debian") is decided based on the source package version
and not the binary package version.
- This is de facto what debhelper does because it does not know the
version of the binary at the time debhelper installs the changelog
(dh_installchangelog is run long before dh_gencontrol).
- Not sure whether this affects lintian (I do not remember the code).
* The remark in chapter 3 about date versioning for native packages is
misplaced and should be in chapter 4 (the one about dashes being
unsuitable for date separators in a native package). Because, a
binary package built from a native source *can* have hyphens in its
version. Both according to the letter of the policy (the "native"
trait only applies to the source package) but also in practice[1].
Assuming we do not agree on the above reading and "native binary
packages" are a thing, then:
* We have at least one instance of a non-native binary built from a
native source that contains hyphens[1] with no open bugs of policy
violations on this matter.
Maybe we should also review this from the angle of "Can a non-native
source package produce binaries without a hyphen?" (e.g., replace "-"
with "+") and still be policy complaint. I would say "no", but tooling
wise, I am certain it is possible. Having a rule that all binaries
built from a source must use the same "native-ness" of the source would
solve this problem but would define java-common to be non-complaint.
However for the reasons stated above, we probably do not *want* to
resolve this by mandating a binary is native based on its own version
regardless of the source version/native-ness. This would lead debhelper
to be non-compliant and in practice unable to become compliant out of
the box.
Additionally, I hope we can improve the policy language around native
vs. non-native and how it relates to binary packages.
Best regards,
Niels
[1]:
$ apt-cache show default-jre | grep -e ^Source: -e ^Version
Source: java-common (0.74)
Version: 2:1.17-74
The java-common source is a native package (version 0.74) but its binary
default-jre is 2:1.17**-**74 and contains a hyphen.
This practice existed for over a decade now as I remember and no one
complained. So the use of hyphens in binary versions are definitely not
causing tooling issues and in my eyes makes this a "common practice"
question rather than a "breaks stuff" question for whether it is allowed.
Feel free to open the on whether decade of use vs. it is only one
package. Either way, the Policy is in my eyes not clear enough / aligned
on this topic on what is allowed and what is not allowed.