Page MenuHomePureOS Tracker

PureOS has no strict policy of mandated packaging requirements
Open, NormalPublic


PureOS have no reliable documentation of what is strictly required.

There is which is helpful as a guideline of what best practices of the PureOS team, but unsuitable as reference e.g. for developing tools to interact with PureOS or for figuring out if a package is severely buggy or just unusually packaged.

Event Timeline

jonas.smedegaard triaged this task as Normal priority.Tue, Apr 27, 00:37
jonas.smedegaard created this task.

@jeremiah.foster: If the current wiki page is as strict as it gets for PureOS and maintaining a more stable subset is considered overkill, then I guess simply close this issue report as wontfix.

I consider the current document to represent the equivalent of a mixture of Debian Developers' Reference and Debian New Maintainers' Guide and the Debian wiki.

@jeremiah.foster: if you agree with that, then I would like to draft the PureOS equaivalent of Debian Policy, directly tied to and compared against and kept in sync with Debian Policy itself.

Yes, let's create a PureOS Policy document. To be clear, we base it on Debian Policy and we add the parts where PureOS deviates. The document is meant to be an authoritative requirements document so ought to use nomenclature to indicate requirement levels either identical to Debian's nomenclature or the IETF nomenclature:

Ok, I will begin drafting a proposed PureOS Policy document, that we can then discuss.

Here's my plan so far:

  1. clone Debian Policy
  2. adapt to comply with GNU Free System Distribution guidelines
  3. adapt to comply with Debian Derivatives Census guidelines
  4. adapt for "upstream first" mindset

Final Policy should be easily comparable with Debian Policy
(e.g. section numbers preserved, with empty placeholders if needed),
and released using a versioning scheme similar to Debian packages
(i.e. DEBIAN_VERSION-MAJOR.MINOR bumping MAJOR with changed meaning).

For all changes, consider if really relevant for Policy
(e.g. "best practices" might be more suitable for a guideline).

Suggestions for things I should take into consideration in my draft work is very welcome.