|Category:||Development ➤ Installation software||Commercial:|
|Released:||Latest : 0.5.1 / Dev : R1012||Package Name:|
|Quality (record):||Quality (game):|
|Contrib.:||Goupil & Louis||ID:||14243|
|[fr]:||Une interface permettant de créer des installateurs agréables, intuitifs et flexibles pour les utilisateurs||[en]:||An Open Source project with the goal to create user friendly and flexible installers that work on various UNIX like systems|
Website & videos
[Homepage] [Dev site] [Features/About] [Screenshots] [Videos t ts gd id r lp g g[fr] g[de] g[ru] g[pl] g[cz] g[sp] g[pt] g[it] g[tr] g] [Reviews] [WIKI] [FAQ] [RSS] [Changelog 1 2]
Commercial : (empty)
[Open Hub] [PCGamingWiki] [MobyGames]
Devs (Rick Helmus [fr] [en]) : [Site 1 2] [twitter] [YouTube] [LinkedIn] [Interview 1 2]
Game : [Blog] [Forums] [twitter] [YouTube]
On other sites
News / Source of this Entry (SotE) / News (SotN)
Une interface permettant de créer des installateurs agréables, intuitifs et flexibles pour les utilisateurs, par Rick Helmus (rhelmus) & contributeurs.
Nixstaller est une interface permettant de créer des installateurs agréables, intuitifs et flexibles pour les utilisateurs, sous différents systèmes UNIX.
Certaines de ses caractéristiques sont les suivantes : petite taille, grande compatibilité, scripting Lua et peu de dépendances.
Utilisé par ces jeux / Used by these games : Fishie fishie,
Nixstaller is an Open Source project with the goal to create user friendly and flexible installers that work on various UNIX like systems.
Nixstaller is an Open Source project with the goal to create user friendly and flexible installers that work on various UNIX like systems. Some of its features are: small size overhead, large compatibility, Lua scripting and few dependencies.
Some of Nixstaller's features:
☑ Installers will be able to run on many common UNIX systems.
☑ Configuration and programming through Lua, allowing simple and powerfull configurations.
☑ Small size overhead.
☑ Not restricted to any type of installation, it's possible to just extract a few files or create an advanced installer that will create system native packages and does dependency checking.
Nixstaller is created with the following goals in mind:
☑ Work on various UNIX like systems. Ideally as much as possible.
☑ Be fully translatable.
☑ Small 'size overhead', meaning that installer packages should not be much bigger than a regular compressed (tar) archive would be.
☑ Run on recent and less recent operating systems.
☑ Very few dependencies, especially for the end user.
☑ Support different frontends, to make sure that the installer will run on as much as possible systems and possibly have a native look.
☑ Make the creation of installers both easy and flexible.
☑ When using 'Package Mode' (see below), the installer's software should ideally be installed by the user's package manager, if not possible scripts will be provided to manage the software. All files, including dependencies, should not conflict with existing files or disturb the package manager.
Most of the feature goals are already implemented, though in future releases many of them will be furtherly extended.
☑ Supported Systems
Nixstaller runs on many different systems, the table below lists those which are currently supported : NetBSD, FreeBSD, Linux, OpenBSD, Solaris
Nixstaller can be fully translated (including any new text coming from scripts). It's up to the install creator if a suitable translation will be autoselected or should be selected by the user.
☑ User interaction
Nixstaller supports both attended and unattended installations.
With attended installations frontends are used to communicate with the end user. The frontends allow the user to control and view the installation process. Because not every system is the same, Nixstaller comes with three different frontends:
• The ncurses frontend is a text based frontend. It should run on almost any system.
• The FLTK frontend is a graphic frontend using X11. Because it's linked staticly it runs on almost every system which has X11 running.
• The GTK+2 frontend is also a graphic frontend, but will only work with systems which have GTK 2.4 and later. For systems such as those using Gnome it will have a 'native' look.
When the installer is run, a suitable frontend is automatically choosen (in order: GTK+2, FLTK, ncurses). The install creator can decide which frontends should be included. As soon as a frontend is launched the user will be presented by several 'installation screens'. These screens are used to communicate with the user and can be used to show an intro, let the user fill in some info, show the installation progress etc. A range of predefined screens exist for most common operations. It's also possible to create new installation screens. The install creator can place a range of different 'widgets' on newly created screens, such as inputfields, checkboxes and images.
Unattended installations don't need any user interaction. The installation process is configured through commandline parameters and any output is directly printed to the console.
The creation of new screens, the installation process itself and configuration of the installer is all done via Lua scripts. Lua is a simple and easy to read and write scripting language. More info can be found on the Lua homepage. The Nixstaller manual also has an extensive Lua guide.
Nixstaller has extended the Lua libraries with a whole range of new functions. These functions are used to communicate with the user's OS (Operating System), interact with the user, install desktop menu entries, extract installation files etc.
☑ Installation Types
Nixstaller is flexible about how the software is installed. Some examples are installers that simply extract some files to a specified location or an installer that will compile software. Nixstaller also has a special installation type called 'Package Mode' which can be used to let the user's package manager package and install the software.
Package Mode is especially handy for software managing (uninstallation, updating). Currently the following package managers are supported: rpm, dpkg (deb), pacman (arch linux) and installpkg (slackware). If the installer is unable to use a package manager (or told not to), the installer will instead simply install the files and create an uninstallation script. When this script is called, it will verify all installed files with MD5 sums before they are removed.
☑ Dependency handling
When using 'Package Mode' (see above) Nixstaller can also handle software dependencies. Required dependencies can easily be found by scanning binaries for required shared libraries. It's also possible to specify your own method for gathering required dependencies. In case a dependency is missing or is (binary) incompatible the user will then either be notified or the installer can install it's own supplied version.
Nixstaller knows two dependency types: simple and full. Simple dependencies don't provide any files and are purely used to let the installer know what to find. If a simple dependency is not found (or incompatible) the installer will warn the user about it. Full dependencies are used to ship dependency files with the installer. In case a full dependency was not found (or incompatible) these files will be installed. Any installed dependency files are installed to a seperate place so they cannot disturb or be disturbed by for example package managers. To keep the size of the installer low one or more full dependencies can be made 'external' so the installer can download them when it needs to.
Nixstaller has a tool that helps the install creator for finding and handling necessary software dependencies. Some of the tool's features are dependency scanning and automatically creating 'dependency packages' (= a bundle of files used to define a dependency).
☑ Other Features
• Creation of desktop menu entries (following the freedesktop standards).
• Installers can be compressed with gzip, bzip2 and lzma.
• The (default) logo and appicon can easily be customized.
• Usage of su or sudo, so that the user can grant the installer root access only when it needs too, instead of running it as the root user.
• To save space, similar frontend binaries are compared to each other and only the differences are packaged with the installer.