search

kornelski / cargo-deb

Make Debian packages directly from Rust/Cargo projects
https://lib.rs/cargo-deb
MIT License
431 stars 52 forks source link

Clarification on the "native" nature of packages #102

Closed git-noise closed 1 year ago

git-noise commented 1 year ago

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 https://github.com/kornelski/cargo-deb/issues/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,

kornelski commented 1 year ago

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.

git-noise commented 1 year ago

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.

kornelski commented 1 year ago

OK, I've made it add -1 revision suffix to make "non-native" packages.