Clarification on the "native" nature of packages
git-noise opened this issue · 3 comments
Hello,
Many thanks for this great tool!
I had a quick question/clarification relating to the "native" nature or not of a package.
As per #25, I understand that this crate is intended to build non-native deb packages (and it also fits what is mentioned on wiki.debian.org here).
However it seems that the current process builds a package which then seems to be interpreted as "native" by a tool like lintian.
If we take the example package that is bundled with the repo, running cargo deb to build the .deb and then running lintian, outputs among other things: wrong-name-for-changelog-of-native-package.
I wondered if it was a side-effect of lintian or if there is some flag that can be included to mark packages as non-native.
Many thanks,
I don't see any explicit flags for this in the deb control file. Documentation for Debian's tools for making deb packages distinguishes native and non-native by how they handle orig tarballs and source packages, but cargo-deb skips these entirely.
I've seen Debian refer to versions "3.0 (quilt)" and "3.0 (native)". cargo-deb currently puts debian-binary file with "2.0". If I put "3.0 (quilt)" as the version, lintian rejects it "dpkg-deb: error: archive has invalid format version: format version followed by junk". If I put "3.0", lintian rejects it too "dpkg-deb: error: archive is format version 3.0; get a newer dpkg-deb".
As a last ditch, I've also tried asking ChatGPT and Bard, and they've hallucinated total nonsense.
So I don't know if it's even possible to mark a package as (non)native.
Many thanks for the feedback!
My initial research before posting here sadly led to the same kind of conclusions.
That being said I was studying two almost identical packages, one native and one non-native and I found out that lintian may actually distinguish between native and non-native packages depending on the version number.
Indeed as per deb packages version scheme [epoch:]upstream-version[-debian-revision], as long as there is a debian revision element, lintian does not seem to consider the package as native. While it makes sense and non-native package versioning is mentioned in the same link I shared above here-again. I am not exactly sure if it is a recommended way.
TLDR: Including a revision number in the [package.metadata.deb] options seems to make lintian consider the package as non-native for its linting purpose.
Finally regarding the 2.0 versus 3.0 (quilt) and 3.0 (native) versions, I think 3.0 (quilt) and 3.0 (native) are "new source package formats", as per https://wiki.debian.org/Projects/DebSrc3.0here, while the latter "new Debian package, version 2.0" is the deb file format version, as per https://en.wikipedia.org/wiki/Deb_(file_format)here - which are two different things, hence the rejection by lintian.
I'll let you determine if you want to make a note of it somewhere in the documentation, and leave this open for the sake of tracking, but feel free to close as/when you see fit.
OK, I've made it add -1 revision suffix to make "non-native" packages.