SprezzOS and Debian

(This document is consciously modeled on "Ubuntu for Debian Developers".)

SprezzOS is proud to be based on Debian, and wants to maintain a healthy and collaborative relationship with Debian developers.

How does SprezzOS differ from Debian?

Debian is a large, worldwide community of volunteers operating under principles of explicit social consciousness, whereas SprezzOS is an investor-directed effort involving comparatively few people. The SprezzOS Project, despite being composed largely of free software, is a commercial endeavor existing at the pleasure, and in the interests, of the Sprezzatura Computing Corporation ("Sprezzatech"). All meaningful differences arise from this distinction. Generally, SprezzOS applauds the aims and decisions of Debian, and most divergences are based on pragmatic (rather than philosophical or technical) concerns.

SprezzOS operates outside the DFSG

The SprezzOS Project has at no time adopted either the Debian Free Software Guidelines, or the Debian Social Contract (of which they are a part). Aside from the fact that doing so would restrict the Project's freedom to include that software it deems fit and useful, the SprezzOS Project has philosophical differences with the DFSG (see "Why SprezzOS?" for more details). As a happy side-effect, SprezzOS can thus remove all changes to upstream which exist only to facilitate the DFSG, which aids in other efforts (see below).

SprezzOS eschews maintainers

Debian relies upon (and explicitly states a design based around) "package maintainers": individuals or teams having primary responsibility for any given source package (where SprezzOS packages have been adapted from their Debian counterparts, these people (at the time of adaptation) are listed as XSBC-Original-Maintainer. Note that no effort is made to update these identifications when the upstream package changes maintainership). This "ownership" ties into privileges to upload new packages. Note that the maintainers' wishes can be overruled by others in Debian, including the Technical Committee, and that "Non-Maintainer Uploads" (NMUs) are a regular occurrence. Ubuntu appears to place all packages under community maintenance, but also to tie "ownership" on their "Launchpad" system to the ability to upload.

SprezzOS aims, to the greatest degree possible, to be automatically constructible. This is a practical necessity for the implementation of other agendas, such as automatic upstream-triggered updates and buildtools-triggered updates. As a result, package autobuilds are triggered by commits to the sprezzos-world git tree, and uploaded following successful autobuild. Commit access to world is an all-or-nothing proposition, and is held by all Sprezzadevs. In an ideal world, no one would need get involved in the packaging process -- updates would be detected on upstream servers, and the package appropriately rebuilt and repacked, all without user intervention. This is necessary for the long-term survival of SprezzOS: without a volunteer community, automation is the only means for keeping the many thousands of packages up to date. With this goal in mind, SprezzOS often makes the following amendments to Debian packages:

• Combination of binary packages. Ideally, every source package would generate exactly one binary package per architecture (multiarch requirements seem to make this impossible given current packaging semantics). Some packages have good reasons for their division, others less so. Unfortunately, using existing packaging tools, construction of multiple binary packages from a given source is most reasonably accomplished via enumerative install manifests. No standard means of automating the addition of new output files to these lists is known. Essentially, anywhere that a division is made according to reasoning that can't easily be summarized in an algorithm, no such means can exist. SprezzOS thus prefers to merge binary packages wherever possible (typical examples include: multiple library binaries from one source, -doc packages, -dbg packages, and plugin packages (even where they add dependency chains to the main package)).
• Minimization of install manifests. The .install files which drive dh_install and CDBS will, wherever possible, be minimized both in number and content. Specification of subdirectories of / and /usr/ is encouraged. Wildcards are considered preferable to explicit enumerations.
• All files must be accounted for. The use of --fail-missing or an equivalent is strongly encouraged (see APT Best Practices). --list-missing is not much better than nothing at all, since most updates will proceed unobserved.

Build deps trigger rebuilds

When a new version of a build-dep is uploaded, it ought trigger an (artificially) acyclic wave of rebuilds (ideally, we would rebuild with cycles until a fixed point was reached, but this is probably not possible in the short term). This is not to be done using the means of, e.g. the DHG, wherein the version of build deps is strictly coded into the package deps. Instead, on the archive side, automated rebuilds will be authored and triggered, with cycles cut off via analysis of the (automatically-generated and thus strictly-formed) changelog entries. This is desirable (a) to reap the benefits of toolchain improvements, (b) to test the new toolchain, and (c) to ensure our source packages continue to build in a current binary environment.

Just say no to patching

Patching the upstream sources is strongly frowned upon in SprezzOS, and Debian patches will be removed wherever possible.

• They create multiple maintenance hassles, and make it more difficult to automatically update packages
• By definition, they create divergence from upstream and fragment the ecosystem
• and, finally, let us never forget this incident.

Where patching is done, SprezzOS adheres to the Debian patching guidelines.

Non-philosophical differences

• SprezzOS currently targets only the amd64 architecture
• SprezzOS currently distributes only the Linux kernel
• The SprezzOS installer broadly diverges from the Debian installer (from which it is forked).
• ZFS is used as a default filesystem and volume manager.
• systemd has replaced sysvinit.
• TCP wrapper support has been removed from most packages.
• Mainline kernel security mechanisms are favored over userspace solutions and esoterica.
  • In particular, SELinux and TCP wrappers are not supported. The former almost certainly introduces security problems (atop the complexity it definitely introduces). The latter are better implemented using iptables.
• The kernel is likely to be more closely tracked in SprezzOS.
• Maximal support of modern hardware is favored over broader support of older hardware.
• Hardening flags are not considered universally desirable.
• Considerable latitude is taken with the Debian Policy Manual, including but not limited to:
  • 4.4 The sprezzos-world git repository is the history of record. Changelog files would ideally be derived automatically from this history. In the meantime, they are officially used only to drive package versioning. Other information ought not be expected therein, though it may at times be provided.
  • 4.5 & 12.5 Life being short, and our time finite, SprezzOS does not require the inclusion nor maintenance of machine-readable copyright files
  • 12.1 Missing man pages ought be reported to either the Debian bugtracker, or the upstream bugtracker if the package was not a Debian package
    • SprezzOS is not in the business of maintaining man pages. If you write one, fork upstream and convince us to use your fork.
  • 12.3 It is desirable that all distributed documentation be installed in the main package.

Archives

• Debian supports three archive areas: main, contrib, and non-free.
  • Please see "Archive Areas" from the Debian Policy Manual for more details.
  • SprezzOS features only two: main and blobs
    • Please see External software from the SprezzOS Handbook for more details.

What kind of changes does SprezzOS make to Debian packages?

This is in no way, and does not attempt to be, a comprehensive list of differences.

d-i and udebs

• Branding is modified in rootskel, main-menu, installer, and netcfg
• A few helper binaries related to the console (fbvfbterm, tangoize, etc.) are added to rootskel
• The i386 images are not built by default
• The gtk installer is not built by default
• Some configuration changes are effected via our initramfs-embedded preseed

Install media

• GRUB2 is used as our bootloader on all media

Kernel

• No firmware is removed for reasons of DGSF incompatibility
• ReiserFS is removed for reasons of project-leader-in-prison incompatibility

Userspace

• Branding is modified in base-files
• Packages are built with a SprezzOS suffix prior to the Debian revision number

What can I do if I feel SprezzOS has acted inappropriately?

Please contact the sprezzos-dev mailing list.

How does SprezzOS cooperate with Debian?

• SprezzOS is an active member of the Debian Derivatives Census
• Bugs common to SprezzOS and Debian are filed in the DBTS

Resources

• The SprezzOS entry in the Debian Derivatives Census.
• The .deb versions matrix is a table of package versions in SprezzOS, Debian, and Ubuntu.

Contact

The SprezzOS project in toto can be reached at the sprezzos-dev mailing list.

The HIC (currently Nick Black) can be reached at spl@sprezzatech.com.

See also

• Debian and SprezzOS, the inverse of this article