Choosing a Distribution Format - RPM, Debian Package or Tarball

Distribution Format Overview

Xi Software provides three distribution formats:

RPM packages

Native package format for Red Hat Enterprise Linux and the distributions built from it

Debian packages

Native package format for Debian

Tarball archives

Compressed tar archive carrying its own installation and de-installation scripts, for platforms with no native package format

All three carry the same software for a given release. The format decides how the files are recorded, what an upgrade does, how long the trial licence runs, and what is destroyed when the product is removed. That last point is the one that costs sites their queue: read What Removal Destroys below before running any removal command.

RPM Distributions

What RPM Provides

Package management integration

Works with the rpm, yum and dnf commands

Declared dependencies

The package names the libraries and interpreters it needs, and the installation is refused if any is absent

File ownership and permissions

Set from the package rather than by an operator

Installation without questions

The package asks nothing. It creates the system user, writes the master configuration, adds the service entries, installs a trial licence, and enables and starts the service

Upgrade in place

rpm -U replaces the binaries and leaves the configuration, the licence and the spool data alone

A 45-day trial licence

Written during installation when no licence file is present already, so the product runs from the moment it is installed

RPM Naming Convention

Current files are named product first:

xitext-standard-1.25.2+1782476379-x86_64-linux-rockylinux9.rpm
xibatch-standard-1.9.0+1782482597-x86_64-linux-rockylinux9.rpm

Older files carry an earlier scheme, and both appear on a download list. The versioning article explains how to read either.

The name recorded inside the package is not the file name. It folds the blend into the product, giving xitext_standard or xibatch_standard, and that is the name every rpm command needs. Find it before you use it:

rpm -qa | grep -E 'xitext|xibatch'

Installing RPM

# Install
sudo rpm -ivh xitext-standard-1.25.2+1782476379-x86_64-linux-rockylinux9.rpm

# Upgrade an existing installation
sudo rpm -Uvh xitext-standard-1.25.2+2.1782476379-x86_64-linux-rockylinux9.rpm

# Using dnf, which resolves the declared dependencies from your repositories
sudo dnf install ./xitext-standard-1.25.2+1782476379-x86_64-linux-rockylinux9.rpm

An upgrade stops the service while it runs. Check the service is running again once it finishes, and start it if it is not.

Removing RPM

# Find the installed package name
rpm -qa | grep -E 'xitext|xibatch'

# Remove it
sudo rpm -e xitext_standard

This removes a great deal more than the files the package installed. Read What Removal Destroys below first.

RPM Compatibility

Built for the Red Hat Enterprise Linux release families 7, 8, 9 and 10 - one build per family, made on CentOS for 7, Rocky Linux for 8 and 9, and AlmaLinux for 10.

Runs on any distribution of the same release family. RHEL, Rocky Linux, AlmaLinux, CentOS Stream and Oracle Linux of a given release are binary compatible with each other, so a package built on Rocky 9 installs on all of them. The distribution named in the file is where the build was made, not a restriction on where it runs.

A build for one release family does not run on another. The package declares the exact library versions it was compiled against, so an attempt to install it on an older release is refused by rpm rather than left to fail later. Take the file whose release family matches the machine:

• centos7 for the RHEL 7 family
• rockylinux8 for the RHEL 8 family
• rockylinux9 for the RHEL 9 family
• almalinux10 for the RHEL 10 family

When to Use RPM

Use RPM packages when:

• The machine runs RHEL or a distribution of the same release family
• You want the installation recorded in the package database and checkable with rpm -V
• You want the installation to complete with nobody at the terminal
• The standard directories suit you - a package installs where it was built to install and offers no choice

Debian Packages

What the Debian Package Provides

Package management integration

Works with the dpkg and apt commands

Declared dependencies

The package names the libraries and interpreters it needs

Installation without questions

As the RPM - the system user, the master configuration, the service entries, a trial licence, and the service enabled and started

A 30-day trial licence

Shorter than the 45 days an RPM or a tarball installation gives. The difference is in the packaging rather than in the product

Debian Package Naming

xitext-standard-1.25.2+1782476379-x86_64-linux-debian13.deb

The name recorded inside the package is the bare product, xitext or xibatch, with the blend carried in the version instead. That is a different arrangement from the RPM, where the blend is part of the name, and it has one consequence worth knowing: apt and dpkg will not move an installation from one blend to another, because a standard build reads as newer than any other blend of the same version.

Installing and Removing a Debian Package

# Install, or upgrade an existing installation
sudo dpkg -i xitext-standard-1.25.2+1782476379-x86_64-linux-debian13.deb

# List the installed Xi packages
dpkg -l | grep -E 'xitext|xibatch'

# Remove
sudo dpkg -r xitext

dpkg checks the declared dependencies and refuses if any is missing; it does not fetch them. Install anything it names with apt first.

There is no "remove but keep my data" option here. dpkg -r destroys as much as dpkg --purge does - see What Removal Destroys below.

Debian Compatibility

Packages are built for Debian 11, 12 and 13, one build per release. As with the RPM, take the file whose release matches the machine.

Ubuntu is a different target. A system running it can be registered, and no build is published for it; ask support.

When to Use the Debian Package

Use the Debian package when:

• The machine runs Debian 11, 12 or 13
• You want the installation recorded in the package database
• You want the installation to complete with nobody at the terminal
• The standard directories suit you

Tarball Distributions

What Tarball Provides

Platform reach

The only format for Solaris, AIX and HP-UX, and available for Linux as well

An interactive installer

An INSTALL script that asks its questions at the terminal

A choice of directories

The installer offers to change the user path, the shared library and include directories, and the spool, internal-programs, help and printer directories, either one at a time or all beneath a common base. The packages install where they were built to install

A de-installation script

DEINSTALL.sh is included. What it removes differs between the two products - see below

A 45-day trial licence

Installed if you do not arrange a full licence during the installation

The installer reads single keystrokes from the terminal and needs root and perl. It cannot be driven from a deployment script, and any arguments given to it are discarded without a message.

Tarball Naming Convention

Tarball names put the platform first, where the package formats put the product first:

x86_64-linux-rockylinux9-xibatch_legacy-standard-1.9.0+1782482597.tar.gz

The versioning article explains the fields.

Extracting Tarball

# Extract the archive
gunzip -c x86_64-linux-rockylinux9-xibatch_legacy-standard-1.9.0+1782482597.tar.gz | tar xf -

# Enter the extracted directory
cd xibatch_legacy-standard-1.9.0/

# View the contents
ls

The two-command form is used because the tarball is the distribution for the platforms with no native package format, and the -z option that decompresses in one step belongs to GNU tar. Solaris, AIX and HP-UX ship their own tar, which has no -z. On Linux tar xzf does the same job.

The directory the archive extracts to is the product, the blend and the version, with the build reference dropped.

Contents:

• INSTALL - the installation script
• INSTALL.sh and INSTALL.pl - the same script under its own name, and the program it runs
• DEINSTALL.sh - the de-installation script; Xi-Batch also carries DEINSTALL.pl
• README and README.html - what the archive holds
• RELEASE - the platform, product, blend, version and build
• BINARY, HELPFILES, MANPAGE and the installer's own directories

There is no file called UNINSTALL.

Installing from Tarball

# Run the installer as root, at a terminal
sudo ./INSTALL

The INSTALL script:

1. Reads any previous installation's master configuration
2. Asks whether you want a full licence now or a trial
3. Offers to change any of the installation directories
4. Creates the system user, asking first
5. Copies the binaries and help files and sets their permissions
6. Adds the service entries and writes the hosts file
7. Arranges start-up at boot
8. Installs the licence

If the product is already running the installer offers to stop it, and gives up if you decline. The installation article covers the questions in full.

Uninstalling Tarball Installation

The de-installer lives in the directory the archive was extracted to and is called DEINSTALL.sh. The two products treat it differently.

Xi-Text takes today's date, as YYYYMMDD, for its argument. That is the confirmation step; it refuses without it, and prints the exact string it wants, so run it once with no argument to see what to type:

cd xitext_legacy-standard-1.25.2/
./DEINSTALL.sh
sudo ./DEINSTALL.sh <the date it printed>

It works from the file list the installer recorded in /usr/lib/xi/install.manifest and stops if that file is missing, so it cannot remove an installation whose manifest has been lost, nor one made from a package. It also has the standard directories written into it, so on an installation whose directories were changed - at installation time, or by a blend - it removes the installed files listed in the manifest but leaves the operational data where it is.

Xi-Batch runs interactively and takes no argument:

cd xibatch_legacy-standard-1.9.0/
sudo ./DEINSTALL.sh

It reads the master configuration, so it follows changed directories, and it asks before removing the service entries and the system user.

Platform Coverage

The tarball is the only format for the proprietary Unix platforms, and it is also published for Linux.

Unix systems:

• Oracle Solaris 10 and 11 on SPARC, and Solaris 11 on x86_64
• IBM AIX 7.1, 7.2 and 7.3 on POWER
• HP-UX 11.23 and 11.31 on Itanium, and HP-UX 11.23 on PA-RISC

Linux: the same release families the packages are built for, where a native package is not wanted.

These are the platforms Xi Software supports, which is a wider list than the set of builds published at any one moment. Builds for the proprietary Unix platforms are produced on request rather than with every release, so a supported platform may show no file on the download portal; ask support for one. There is no build for FreeBSD or the other BSDs, for Fedora, or for Arch.

When to Use Tarball

Use tarball distributions when:

• The machine runs Solaris, AIX or HP-UX, where it is the only format
• You need the product in directories of your own choosing
• You would rather the installation was not recorded in the package database
• You have a terminal, root and perl available for the installation, and someone to answer the questions

What Removal Destroys

Removing the product is not a file deletion. Every route also removes state that was never part of the distribution - the queue, the licence, the configuration, the system account - and only one of the routes asks you first. Take a copy of anything in this table you intend to keep before you start.

The licence is the item most often lost. A package removal deletes the licence file without warning, and a fresh installation then writes a trial licence in its place - so the product keeps running and nothing appears to be wrong until the trial expires weeks later. The licence file is a hidden file in the internal-programs directory, /usr/libexec/xi/.xitext.lic or /usr/libexec/xi/.xibatch.lic on a standard installation. A blend, or a tarball installation whose directories were changed, puts it somewhere else; read the internal-programs directory out of the master configuration rather than assuming.

An upgrade is different from a removal. Upgrading a package in place keeps everything in this table.

Comparing the Three Formats

Migration Between Formats

Moving a working installation from the tarball to a package, or from a package to the tarball, is a re-installation of the same software on the same machine. Nothing in the product objects to it. What goes wrong is that the removal step throws away the licence and, on most routes, the queue as well - so the order below matters more than the commands do.

1. Establish what you have. If rpm -qa or dpkg -l names the product, it is a packaged installation; if neither does, it is a tarball installation. Read the real directories out of /etc/xi/textconfig or /etc/xi/batchconfig rather than assuming the standard ones.
2. Stop the product, then export the configuration and the queue with the product's own conversion tools. An export taken from a running system can be several minutes behind it.
3. Copy the licence file out of the installation to somewhere the removal cannot reach - /root, or your backup. This is the step that is missed.
4. Remove the old installation by its own route, having read What Removal Destroys above.
5. Install the new format.
6. Put the saved licence file back, over whatever trial licence the installation wrote, in the new installation's internal-programs directory. Then run xt-checklic or xb-checklic and confirm the licence and the end date are the ones you had.
7. Restore the configuration and the queue from the export.
8. Start the product and verify that the queue, the printers or variables, and the user permissions are as they were.

The licence survives the change of format. It is tied to the machine, not to the installation, the directory or the package format, so the same licence file is valid after the move provided the hardware has not changed. If checklic reports it invalid after the move, the machine's identity has changed rather than the licence, and you need new codes from the customer portal.

Two cases need more than this. Changing the blend at the same time moves every directory, and is not something either package manager will do for you; see the blends article. And a tarball installation whose directories were customised cannot keep them under a package, because a package installs where it was built to install - plan for the move, and check the licence file's new location in particular.

Recommendations

For RHEL, Rocky Linux, AlmaLinux, CentOS Stream and Oracle Linux: Use the RPM package built for your release family.

For Debian: Use the Debian package built for your release. Older advice sent Debian sites to the tarball; Debian has a native package and it is the right file to take.

For Ubuntu and SUSE: A system running either can be registered, and no build is published for either. Ask support before you plan the installation.

For HP-UX, AIX and Solaris: Use the tarball for your hardware. It is the only format, its installer needs a terminal, root and perl, and the build may have to be made for you rather than taken from the portal - allow time for that.

Where you need the product in directories of your own: Use the tarball on any platform. A package cannot be persuaded to install elsewhere; only a blend arranged by Xi Software changes a package's directories.

For a mixed estate: Use the native package wherever there is one and the tarball where there is not, and expect the trial period to differ between them.

Getting Help

RPM installation issues: Find the installed name with rpm -qa | grep -E 'xitext|xibatch', then check the files against the package with rpm -V and that name.

Debian package issues: Find the installed name with dpkg -l | grep -E 'xitext|xibatch', then check the files with dpkg -V and that name.

Tarball installation issues: Review the installer's output at the terminal. It reports what it is doing as it goes, and the terminal is the only place that report appears, so capture the session if you may need it.

Format selection questions: Contact support@xisl.com for guidance.

All three formats carry the same software for a given release, and the product behaves the same way whichever you install. What the format decides is where the files come from, whether the installation asks questions, how long the trial licence lasts, and what a removal takes with it.