> 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.