Choosing a Distribution Format - RPM, Debian Package or Tarball

Both productsXi-BatchXi-Textinstallationpackagingplatformsremoval

The download list offers the same release as an RPM, a Debian package and a tarball. This article says what each format does to the machine, and which one to take.

The three formats

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 a removal takes with it. Read What a removal takes with it below before running any removal command.

RPM distributions

What the 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

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

How an RPM file is named

Current files are named product first:

xitext-<variant>-1.25.2+1782476379-x86_64-linux-rockylinux9.rpm
xibatch-<variant>-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 blend field is written above, and in the commands below, as \ - substitute the value your own file carries.

The name recorded inside the package folds the blend into the product, giving xitext_\ or xibatch_\, and that is the name every rpm command needs. Find it before you use it:

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

Installing and upgrading an RPM

# Install
sudo rpm -ivh xitext-<variant>-1.25.2+1782476379-x86_64-linux-rockylinux9.rpm

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

# Using dnf, which resolves the declared dependencies from your repositories
sudo dnf install ./xitext-<variant>-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 an RPM

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

# Remove it
sudo rpm -e xitext_<variant>

This removes a great deal more than the files the package installed. Read What a removal takes with it below first.

Which machines an RPM runs on

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 records where the build was made.

A build for one release family does not run on another. The package declares the exact library versions it was compiled against, so rpm refuses an installation on an older release. 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 the 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
Where an RPM or a tarball installation gives 45. The difference is in the packaging

How a Debian file is named

xitext-<variant>-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: apt and dpkg will not move an installation from one blend to another, because the blend sorts alphabetically, so a build of one blend never reads as newer than a build of another of the same version.

Installing and removing a Debian package

# Install, or upgrade an existing installation
sudo dpkg -i xitext-<variant>-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.

dpkg -r removes as much as dpkg --purge does - see What a removal takes with it below.

Which machines a Debian package runs on

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 the 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 where you do not arrange a full licence during the installation

The installer reads single keystrokes from the terminal and needs root and perl, so it is answered by hand. Any arguments given to it are discarded without a message.

How a tarball file is named

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

x86_64-linux-rockylinux9-xibatch_legacy-<variant>-1.9.0+1782482597.tar.gz

The versioning article explains the fields.

Extracting the archive

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

# Enter the extracted directory
cd xibatch_legacy-<variant>-1.9.0/

# View the contents
ls

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, so the two-command form above works on every platform the tarball serves. 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 the 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.

Removing a 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-<variant>-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 default 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-<variant>-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.

Which machines the tarball runs on

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, 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 the 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 want the installation left out of the package database
• You have a terminal, root and perl available for the installation, and someone to answer the questions

What a removal takes with it

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

What happens to	RPM or Debian package	Tarball, Xi-Text	Tarball, Xi-Batch
Spool data - the queue and the saved job, printer and user files	Deleted	Saved job, printer, user and report files deleted	Kept
Licence file	Deleted	Deleted	Kept
Master configuration and hosts file in /etc/xi	Deleted; /etc/xi itself goes too unless the other Xi product is installed	Deleted	Deleted
System user (spooler or batch)	Deleted	Kept	Deleted if you agree
Service entries in /etc/services	Deleted	Kept	Deleted if you agree
The product is stopped first	Stopped and disabled for you	Stopped for you	You are asked; it gives up if you decline

The licence is the item most often lost. A package removal deletes the licence file, 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 where the default directories are in force. 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.

Upgrading a package in place keeps everything in this table.

The three formats side by side

Feature	RPM	Debian package	Tarball
Package management	Integrated	Integrated	None
Installation	No questions	No questions	Interactive, needs a terminal
Removal	rpm -e	dpkg -r	DEINSTALL.sh
Upgrades	rpm -U	dpkg -i	Stop, run INSTALL again, start
File tracking	In the package database	In the package database	Xi-Text records a manifest; Xi-Batch records nothing
Platforms	RHEL families 7 to 10	Debian 11 to 13	Solaris, AIX, HP-UX and Linux
Directories	Fixed by the build	Fixed by the build	Chosen during installation
Dependencies	Declared and checked	Declared and checked	Neither declared nor checked
Trial licence	45 days	30 days	45 days

Moving from one format to another

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. The removal step takes the licence with it 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 a removal takes with it 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 remains valid across a change of format. It is tied to the machine, so the same licence file is valid after the move as long as the hardware is unchanged. Where checklic reports it invalid after the move, the machine's identity has changed, 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 neither package manager will do it 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.

Which file to take

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

Checking an installation, and where to ask

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.

Related articles

All articles · Release notes · Contact support