Packages which are available on Debian and are changed in PureOS have a `pureosX` version tag attached to the Debian revision, with `X` being the PureOS revision number. So, if the package's upstream version is `2.1`, it's Debian revision is `2` (creating the Debian version string `2.1-2`) and you make a change for PureOS, the resulting package version must be `2.1-2pureos1`. The PureOS revsion is incremented with every change, so the next version would be `2.1-2pureos2`. This is also true for `3.0 (native)` packages that don't have a Debian revision so e.g. `2.1` turns into `2.1pureos1`. If the package isn't in Debian, the Debian revision number is assumed to be zero and all other rules from above still apply. So, an upstream package with version `3.4` which is new in PureOS will get the initial version `3.4-0pureos1`. If you do not do any source changes but just rebuild a package, `bX` is appended to the revision. So, a package of version `1.0-3` gets the new version `1.0-3b1` if it is rebuilt. The rebuild version is incremented on every subsequent rebuild. If the archive rejects an upload because a `+bX` version number exists, then this is because of a binary package sync from Debian where the package was binNMUd before. In this particular case, please upload the package again, but append a `+` before the PureOS version, so `1.0-1pureos1` becomes `1.0-1+pureos1`. Paying attention to the version numbers is important, because the PureOS archive tools will use the version number to make decisions about the package's state, which includes overriding it with a version from Debian or even removing it. Using the right version number will make the archive do the right thing. You might be able to use `DEBEMAIL=first.last@puri.sm dch --distribution=landing --force-distribution --no-auto-nmu --local=pureos` as a starting point.

Packages which are available on Debian and are changed in PureOS have a `pureosX` version tag attached to the Debian revision, with `X` being the PureOS revision number. So, if the package's upstream version is `2.1`, it's Debian revision is `2` (creating the Debian version string `2.1-2`) If you make a change for PureOS, the resulting package version must be `2.1-2pureos1`. The PureOS revision is incremented with every change, so the next version would be `2.1-2pureos2`. This is also true for `3.0 (native)` packages that don't have a Debian revision so e.g. `2.1` turns into `2.1pureos1`. If the package isn't in Debian, the Debian revision number is //assumed to be zero// and all other rules from above still apply. So, an upstream package with version `3.4` which is new in PureOS will get the initial version `3.4-0pureos1`. If you do not do any source changes but just rebuild a package, `bX` is appended to the revision. So, a package of version `1.0-3` gets the new version `1.0-3b1` if it is rebuilt. The rebuilt version is incremented on every subsequent rebuild. If the archive rejects an upload because a `+bX` version number exists, then this is because of a binary package sync from Debian where the package was binNMU'd* before. In this particular case, please upload the package again, but append a `+` before the PureOS version, so `1.0-1pureos1` becomes `1.0-1+pureos1`. Paying attention to the version numbers is important, because the PureOS archive tools will use the version number to make decisions about the package's state, which includes replacing it with a version from Debian or even removing it. Using the right version number will make the archive do the right thing. You might be able to use `DEBEMAIL=first.last@puri.sm dch --distribution=landing --force-distribution --no-auto-nmu --local=pureos` as a starting point. * binNMU'd = "Binary non-maintainer upload"

Packages which are available on Debian and are changed in PureOS have a `pureosX` version tag attached to the Debian revision, with `X` being the PureOS revision number. So, if the package's upstream version is `2.1`, it's Debian revision is `2` (creating the Debian version string `2.1-2`) and If you make a change for PureOS, the resulting package version must be `2.1-2pureos1`. The PureOS revision is incremented with every change, so the next version would be `2.1-2pureos2`. This is also true for `3.0 (native)` packages that don't have a Debian revision so e.g. `2.1` turns into `2.1pureos1`. If the package isn't in Debian, the Debian revision number is //assumed to be zero// and all other rules from above still apply. So, an upstream package with version `3.4` which is new in PureOS will get the initial version `3.4-0pureos1`. If you do not do any source changes but just rebuild a package, `bX` is appended to the revision. So, a package of version `1.0-3` gets the new version `1.0-3b1` if it is rebuilt. The rebuildt version is incremented on every subsequent rebuild. If the archive rejects an upload because a `+bX` version number exists, then this is because of a binary package sync from Debian where the package was binNMUd'd* before. In this particular case, please upload the package again, but append a `+` before the PureOS version, so `1.0-1pureos1` becomes `1.0-1+pureos1`. Paying attention to the version numbers is important, because the PureOS archive tools will use the version number to make decisions about the package's state, which includes overridingreplacing it with a version from Debian or even removing it. Using the right version number will make the archive do the right thing. You might be able to use `DEBEMAIL=first.last@puri.sm dch --distribution=landing --force-distribution --no-auto-nmu --local=pureos` as a starting point. * binNMU'd = "Binary non-maintainer upload"