Build Blends - What They Change and Which One You Are Running
A release variant that installs into different directories: what changes, and how to tell which one you are running
A blend is a named variant of a release, and one of the fields in every distribution file name. This article says what a blend changes and how to read which one your installation runs. Where an example here needs a blend, the field is written as \
A blend changes where the files are installed
Every blend of a release is built from the same source at the same release version and the same format version, so the programs are the same programs and the job, queue, printer and licence file formats are the same formats. In a distribution file name, and in the directory a tarball extracts to, the blend sits here:
xibatch-<variant>-1.9.0
xitext-<variant>-1.25.2
The blend is recorded against your account, and against each system you register, in the Xi Software portal. Every account has the default build; any other blend is one Xi Software has arranged for that account, on request to support.
The three kinds of build
The default build
The general-purpose build, produced for every supported platform. It is what almost every installation runs, and its directories are the ones documented throughout this knowledgebase.
A build arranged for a site
A variant Xi Software has arranged for a particular installation. What such a build most often changes is where the files are installed; the programs, the commands and the file formats are those of the release it was built from.
A diagnostic build
A build issued by Xi Software support for the duration of an investigation. The scheduler writes a running commentary to its error output, which on a systemd installation goes to the service journal, and the programs are compiled without optimisation, so they are larger and slower.
The directories a blend moves
These are the default locations, which are the ones the rest of this knowledgebase quotes:
| Directory | Default location |
|---|---|
| Internal programs | /usr/libexec/xi |
| Help files | /usr/share/xi |
| Xi-Batch spool data | /var/spool/xi/batch |
| Xi-Batch sockets | /var/spool/xi/btuds |
| Xi-Text spool data | /var/spool/xi/spd |
| Xi-Text sockets | /var/spool/xi/spuds |
| Xi-Text printer setup files | /var/spool/xi/printers |
Two locations are the same on every blend: the configuration directory /etc/xi, and the user commands in /usr/local/bin. Everything installed beside the internal programs moves with them, including the licence file.
Where a blend has moved these directories, the values in use are recorded in the master configuration file under /etc/xi, and the installed package can be asked which files it put where. Read your own paths from there when a procedure elsewhere in this knowledgebase names a directory your system does not have.
Reading the installed blend
No Xi-Batch or Xi-Text command prints the blend, and the version string compiled into the programs does not carry it. There are four places to look.
On an RPM installation, the installed package name carries the blend after an underscore:
rpm -qa | grep -i xitext
This gives a name such as xitext_\
On a Debian installation, the package name is the product alone and the blend is part of the version, following the plus sign:
dpkg -l | grep -i xitext
# ii xitext 1.25.2-1+<variant>.1782476379 amd64 Xi-Text Spooler
The installed directories answer the question without any package query: internal programs anywhere other than /usr/libexec/xi means a blend that has moved them.
The master configuration file under /etc/xi records the directories the build was made with, in its SPROGDIR, SPOOLDIR and related settings. A setting still at the value compiled into the build is written as a comment line; the value shown is the one in use.
Your registered systems in the Xi Software portal also record the blend each one runs.
Updating and changing blend
Version numbers
A blend carries the same release version as the default build of the same software. Where a blend is produced after that version has been released, it ships as a further revision of it, so the version matches and the build reference differs.
Updating within a blend
An update to the blend you already run is an ordinary update, and follows the procedure for your distribution format.
Changing blend is a different operation
Blends are separate packages. On an RPM installation the installed package name carries the blend, so two blends are two distinct packages. On a Debian installation the package name is the product alone and the blend is part of the version, where it sorts alphabetically rather than by date, so a build of one blend never presents itself as newer than a build of another, and a package manager will not move a system between blends on its own. The directories move as well. Ask Xi Software support before changing the blend of a running system.
Testing
Packaged blend builds are verified against the blend's own installed paths before release.
Blend and version compatibility
Same version, different blend
The formats are identical, so saved jobs, queue files and user files written under one blend are read under another of the same version, and the two interoperate over the network.
Moving data between blends
The files are the same and the directories differ, so anything copied across is placed under the receiving system's directories.
Different versions
What decides whether two installations can exchange files is the format version, which a blend leaves unchanged. See the article on product versioning.
Downloading a build of your blend
Builds are obtained from the Xi Software customer portal at https://product-management.xisl.com/login, under the panel for the serial number concerned. The list carries every blend the account is entitled to, and that always includes the default build, so a blend customer sees both and the blend field in the file name is what distinguishes them. The article on downloading from the portal gives the full procedure.
The licence is issued against the machine
The blend forms no part of it: the record the products validate holds the serial number, the start and end dates, the entitlement flags and the site name. The same codes are valid whichever blend of a product you run.
The licence file itself is installed beside the internal programs, so it moves with the blend - /usr/libexec/xi where the defaults are in force, and otherwise the internal-programs directory named in the master configuration.
Related articles
Choosing a Distribution Format - RPM, Debian Package or Tarball
What each format gives you, which platforms have which, and what an upgrade or removal does to your queue and licence
Downloading Xi Software from the Customer Portal
Signing in with a one-time code, what the portal offers for each registered system, and why a download may be withheld
Installing Xi-Text and Xi-Batch Without Answering Questions
What the INSTALL script does and does not automate, and how to script an installation from the packages