How OSTree/Ostbuild replace packages

Here we're going to walk through a representative RPM spec file, and discuss how OSTree eliminates the need for each part. All of this applies to .deb too, it's just more convenient to look at a single file.

The full file we're looking at is http://pkgs.fedoraproject.org/gitweb/?p=glib2.git;a=blob;f=glib2.spec;h=bf9b690d1cd89f26faf3f4b083d9e49a70c9f7fb;hb=HEAD.

Summary: A library of handy utility functions

If you don't know what something does, look in the git repository for a README. We don't need to ship this to every client system.

Name: glib2

This acts as both a source package name and a binary package name. Ostbuild does have the concept of source names. It doesn't have the concept of binary package; there are no runtime dependencies, no ability to independently add and remove binaries.

Version: 2.31.17
Release: 1%{?dist}

These bits are both replaced by a git revision.

License: LGPLv2+

There is at present no tagging of licenses; again, look in the upstream.

Group: System Environment/Libraries

No one cares.

URL: http://www.gtk.org

Look in the upstream git repository.

Source: http://download.gnome.org/sources/glib/2.31/glib-%{version}.tar.xz

Replaced by git revision.

BuildRequires: pkgconfig
...

Ostbuild gets around this by simply having a list of things to build in order. Long term we may want to query build dependencies from individual components.

Requires: shared-mime-info

There are no binary packages in OSTree, and thus no runtime dependencies.

%description
GLib is the low-level core library that forms the basis for projects
such as GTK+ and GNOME. It provides data structure handling for C,
portability wrappers, and interfaces for such runtime functionality
as an event loop, threads, dynamic loading, and an object system.

If you don't know what something does, look in the git repository for a README. We don't need to ship this to every client system.

%package devel

Ostbuild will use the Build API to split between runtime/devel automatically.

%package static

Admittedly there's no replacement for this. But no one should be using static libraries in 2012.

%prep
%setup -q -n glib-%{version}

Totally pointless repetitive boilerplate. We check out one git repostitory and we know the source code is in the directory we checked out.

%build
...
%install
...

Replaced by the build API.

%post
...
%postun
...

These are centralized in the OSTree trigger mechanism.

%files

This is by far the worst part of packages, because it makes continuous integration impossible. It means that if the "upstream" adds a new binary for example, it needs to be added here. This concept of "which files go where" should also be replaced by the build API.

%changelog

Because we've now eliminated the entire concept of packages, there's no reason to have a changelog for them. Also, the idea of changelog-inside-a-file when the RPM specs should themselves be in version control is fantastically stupid.