-
Notifications
You must be signed in to change notification settings - Fork 16
getting started
Note: This page is a work in progress, with incomplete content. If you are building an RPM distro, one production-ready solution to run swupd-server is the Mixer, used by the Clear Linux OS to build releases.
This guide provides a basic overview to using swupd-server.
Both swupd-server and swupd-client (hereafter referred to as SWUPD) use bundles to describe collections of software. This concept is very similar to "package groups" used by other software update or package management systems. However, SWUPD is different in that it only understands bundles, not individual packages. For an overview of how Clear Linux uses bundles, see the bundle overview.
To define a bundle for swupd-server to use:
- Create a new workspace directory to store your bundle definitions, and create a bundles directory inside. It is recommended to make the workspace a git repository so that you can track bundle history.
$ mkdir ~/my-bundles; cd ~/my-bundles
$ mkdir bundles; cd bundles
- Create a new file with a name that describes the bundle. Here, we will create a bundle named "os-core", since swupd-server requires a bundle with that name. Only the bundle file name is important to swupd-server so that it knows to generate update content for it -- this is described later. The contents of the file are optional, but can be used for defining the bundle contents.
$ touch os-core
In the case of Clear Linux, bundle contents are defined within the bundle files as a list of RPM subpackages that comprise the bundle. For instance, if the os-core bundle should include three subpackages (filesystem, glibc, and linux), then the Clear Linux bundle definition could be created as follows:
$ cat > os-core << EOF
filesystem
glibc
linux
EOF
Then, those three subpackages would be installed with an RPM package manager (yum, etc.) to a chroot in a special location recognized by swupd-server (see the next section for details).
But, there is no requirement to use RPMs/DEBs/etc to describe bundles. Other approaches are possible.
Bundle files could include the location of a pre-built chroot to use instead:
$ cat > os-core << EOF
/home/user/my-custom-bundle/
EOF
And then some tooling could copy the complete file hierarchy (chroot) within /home/user/my-custom-bundle/ to seed the location recognized by swupd-server (see the next section).
However the chroots are created does not matter. But one bundle definition must map to one chroot. The next section describes where to populate the chroots for use by swupd-server.