Packaging Overview
Prerequisites
To build packages, install the devscripts package: sudo apt install devscripts, which contains a lot of useful helpers for building Debian packages.
Having gbp available is also a good idea: sudo apt install git-buildpackage
Building packages
All packages have to be built in a pristine PureOS landing chroot before being uploaded to PureOS. The preferred method to do that is by using pbuilder.
For packages not managed in Git, pbuilder can be invoked via
DIST=landing pdebuild --auto-debsign
For Git-managed packages, gbp provides options to build with pbuilder directly. Alternatively, pdebuild can be passed in like gbp buildpackage --git-builder='DIST=landing pdebuild --auto-debsign'
Don't forget to set your own email address for the Git repository, via git config user.email your.name@puri.sm.
Version numbers
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.
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, and 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.
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 dch --distribution=landing --force-distribution --no-auto-nmu --local=pureos as a starting point.
Validating packages
Use lintian --profile=pureos -IE --pedantic <changes-file> to check a package for compliance with the Debian policy. Ensure it is warning and error-free.
If your Lintian is old and does not support the pureos profile, all warnings related to NMUs and invalid suites can be ignored, as those are different or don't exist in PureOS. (See https://bugs.debian.org/884408)
- Last Author
- chris.lamb
- Last Edited
- Dec 15 2017, 01:33
Event Timeline
Feel free to delete my draft which arouse out of confusion around the Uploaders: field ;)
I would delete it myself, but have no clue how :O
@evangelos.tzaras no idea how one drops drafts but i think i restored the original version.
the main development branch should be called debian/latest
I believe that should be pureos/latest instead.
So would that be pureos/latest (instead of pureos/byzantium) and pureos/amber or pureos/amber-phone then?
Confusing!
Using pureos/byzantium or pureos/amber with or without -phone is somewhat easier for me since it clarifies which branch is destined for which target suite. In my mind, pureos/latest points to the branch that you work from to create pureos/*.
- @guido Am I right in this thinking with pureos/latest?
- @evangelos.tzaras How can we make this less confusing?
I was mostly confused whether this would imply that we would have both pureos/latest and pureos/byzantium.
Might also have been a case of -ENOCOFFEE, so feel free to disregard the confusion ;)
@evangelos.tzaras you only have *both* `pueros/latest and pureos/byzantium once byzatium is no longer the current development version. See https://dep-team.pages.debian.net/deps/dep14/ . The upside of pureos/latest is that you'd not be constantly busy with switching the repos default branch and name. It's basically the same as we do within DebianOnMobile with debian/master.