Suppose you want to create an installer for the Linux platform for an app that you created using PyInstaller. Your concern is user friendliness.
This is about the process in general. (I intend to publish a followup with the specifics.)
A similar tutorial about short-cutting Debian packaging, is about a command line app, and not user-friendly.
This post is about getting your foot in the door: publishing an app outside the main channels of distribution, but that installs in a user-friendly way .
The ancient sense of ‘install’ software
It’s not user-friendly. A user deeply understands the process of installing, and the OS. The user uses a command line in a terminal or console. The user downloads a binary and fiddles with system directories to copy the executable to some ‘bin’ directory. The name of the program file is the command to execute it. The app has no visual icon, no aliases.
Worse, ‘install’ could mean: download source code, compile it, and THEN install the binary. That’s not necessarily hard: it is often reduced to three commands: .configure, make, and make install. But that sometimes is a trip to ‘dependency hell’. And it often yields only a command line app.
The modern, user-friendly sense of ‘install’ software
- a user clicks a ‘Download’ button in a web page to start the process
- the download automatically uncompresses itself (unzips) to a ‘package’ (a specialized archive of component files)
- an installer automatically starts, or starts when a user clicks on the downloaded ‘package’
- your app will be “integrated with the desktop”, that is, have a clickable icon in the usual places.
- the OS will remember how to uninstall the app
A file that installs an app. The file is executable, and usually clickable to run. A self-installer is both an ‘installer’ and a ‘package.’ As a file it comprises : an installer and the package it installs. When it runs, its installer installs the package (which may involve uncompressing and unarchiving the package as well as other installing subprocesses.)
An app has resources
Resources are non-executable objects that an app needs to run, for example images (icons, etc.) and sounds.
Resources are packaged with the executable of an app.
Resources needed for packaging include:
- resources the app needs to run (run resources)
- resource the installer needs to install the app (install resources), the most important of which is the ‘app icon’
For command line apps, install resources might include man pages.
More generally, install resources are the objects that a user and the OS expects for a ‘well-behaved’ program. What ‘install resources’ comprises, depends on the sophistication of the user and the OS.
PyInstaller is NOT an installer
As discussed in the PyInstaller FAQ
No, despite its name (which has more to do with its historical roots), PyInstaller is used to transform a Python program into a native executable form which does not require existing Python installations to run. Building an installer program is totally outside the scope of PyInstaller.
PyInstaller produces a binary with no dependencies. A user can ‘install’ it in the ancient sense, but no in the modern, user-friendly sense. One goal of PyInstaller is to avoid ‘dependency hell.’
PyInstaller deals with run resources, but not install resources.
Package managment means the apps (tools) a user (in the system administrator role) uses to install and otherwise manage applications (more generally, software.)
There are competing ways of packaging and package management in the Linux world
There is no consensus, no standard. Alternatives:
- Debian packaging
- RPM packaging
- YUM packaging
Some Linux distributions understand several of the alternatives.
The Linux packaging process is hard
It’s for artisans, cognesceti, wizards.
This Debian packaging tutorial gives you the flavor of how hard.
But that is for programmers who want to become part of the community, or want their application to enter the mainstream of the community.
This post is about getting your foot in the door: publishing an app outside the main channels, but that installs in a user-friendly way .
Debian packages are clickable but not self-installers
Most Linux OS distributions understand Debian packages and start an installer when a Debian package file (.deb) is clicked. For example, on Ubuntu, the ‘Ubuntu Software Center’ starts.
The Linux standard for well-behaved, desktop apps
The FreeDesktop organization promulgates ‘pseudo’ standards for this. They don’t enforce them.
On Windows and OSX, corporations set and enforce the standards.
For our purposes, the Desktop Entry Specification is pertinent. It is about how the OS presents your app to the user, or program shortcuts (clickable icons.)
The Debian standard for packages
The Debian community is concerned with Linux as a command line OS, not with the desktop metaphor.
The Debian Policy Manual specifies the standard, and there is no concise specification. You must read that document, looking for “package .*must have”. That document doesn’t always tell you the consequences (for installing) of failing the requirements. For example, it says if the man page is missing, it is considered a bug, but the package will still install.
Much of that document is concerned with version and dependency, that is, stuff a package manager needs.
Much of that document is concerned about ‘run resources’: bundling what the app needs.
From a brief skim, these ‘install resources’ are required:
- a man page
- a copyright and license