> Managing overlays

There are some assumptions in the build process based on my personal environment, namely that lots of stuff is present under the directory /packages/localsrc/Tribblix which I have as an environment variable THOME. You'll need THOME set for much of the following to work.

Initial setup

You'll need to check out one or more of the 3 overlay sources.

cd $THOME
git clone https://github.com/tribblix/overlays
git clone https://github.com/tribblix/overlays.lx
git clone https://github.com/tribblix/overlays.sparc

You'll also need the build repo, because some of the shared scripts are supplied there (rather than each set of overlays having a duplicate copy).

cd $THOME
git clone https://github.com/tribblix/build

Differences between the repos

In general, the intention is that the overlays available for the different variants should be as similar as possible.

lx vs vanilla

The lx version is slightly different, only because OmniTribblix has a couple of extra features. The only differences should be:

• The base overlay for lx includes inotify and the lx zone brand
• The lx variant has the azure-baseline and hyperv overlays

In general, though, the application overlays for lx should be identical to the vanilla version. The actual packages are shared between the variants, so there's no reason for any differences.

x86 vs sparc

The sparc version can be quite different. There are significant differences in the packages that come from illumos - the packages are named differently in some cases, and there's a different set of drivers. And in terms of applications, software availability on sparc is quite a bit worse (there's no go or rust, for example, so anything requiring those won't exist on sparc at all).

Some of the overlays make no sense at all on sparc (for example, anything related to cloud).

Related to software availability, some packages for sparc are downrev compared to x86. (In many cases a later version has been rewritten in rust, for example, which means we can't update.) That also means that the list of dependencies can be quite different.

How the overlays work

There are 2 files for each overlay. The ovl file is metadata, and the pkgs file is simply the list of constituent packages.

Generally, I try to normalise the overlays a bit. In other words, overlays are layered, so you don't have to duplicate packages between overlays too much. That's more of an aspiration than a hard rule. Dependencies between overlays are expressed as a REQUIRES entry in the ovl file.

Adding a new overlay requires creating both files.

Adding new software is simple a case of adding the package to the pkgs file and bumpoing the version in the ovl file.

The overlays should be consistent (see the next section for checks), although there are missing dependencies in some of the core packages. This is deliberate (for example, perl is missing from the live image which makes it slightly wrong, but that's a known case and handled correctly).

Validation

The validation scripts are shared and come from the build repo.

To check the dependencies are consistent:

cd ${THOME}/overlays
../build/overlay-depends -a

If there's something missing you can see why for a given overlay:

cd ${THOME}/overlays
../build/overlay-depends -v develop-extras

You can also check that all the packages actually exist:

cd ${THOME}/overlays
../build/check-overlay-pkgs -a

Note that a lot of this assumes that you have a copy of the illumos packages as built earlier to check against.

Index | Previous Section