SprezzOS and Debian

From SprezzOSWiki

(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?

There is one primary difference between SprezzOS and Debian: Debian is a large, worldwide community of volunteers, whereas SprezzOS is a commercial project with very few people involved. The SprezzOS Project, despite being composed largely of free software, is a commercial effort. It exists at the pleasure and in the interests of the Sprezzatura Computing Corporation ("Sprezzatech"). All meaningful differences flow from this distinction.

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 SprezzOS Project has adopted neither the Debian Free Software Guidelines nor the Debian Social Contract (of which they are a part).
  • 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.
  • Updates to the toolchain result in immediately-scheduled rebuilds of affected packages.
  • 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

Archives

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?

Resources

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