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 DEBEMAILemail@example.com dch --distribution=landing --force-distribution --no-auto-nmu --local=pureos as a starting point.
- binNMU'd = "Binary non-maintainer upload"