Modular Installer Ideas

From Wiki [en] OpenMandriva
Jump to: navigation, search

The main disadvantage of current installation process of OpenMandriva is lack of modularity - we simply unpack a single squashfs with preinstalled packages into user's machine, and user has no way to choose which packages to install and which to drop.

One of the possible alternatives is per-package installation. However, it has even more disadvantages:

  1. It is much slower, since during rpm installation the system not only unpack the archive, but also launches pre- and post-scripts, file triggers, etc.;
  2. The number of packages in modern repositories is huge (> 10,000), and it is unlikely that users will be able to really walk through the list of packages during installation

Another possibility is to use several smaller squahfs images to provide users with high-level choices - e.g., install KDE or Gnome, install games, office, multimedia, etc. That is, during the installation user may choose "KDE + games + office" and the installer should then unpack three corresponding squashfs images. Some of that images can be mutually exclusive (e.g., KDE vs Gnome), while the others can be supplemental and compatible with any combination of other images.

In general, it's not hard to unpack several squashfs images on the same disk partition if there are no file conflicts. However, such a conflict does exist and its name is 'rpm database'. The thing is that there should be a single rpm database that will contain information about all packages installed in the system. So if you unpack several squashfs images, you should somehow create a database which will contain information about them.


One of the possible approach is used by MagOS Live system (which was initially based on Mandriva and now uses ROSA repositories). MagOS provides several modules - squashfs images with a set of preinstalled packages. Modules don't contain rpm database, but provide a list of packages (as a plain text) installed in them. There is a single "main" module which contains rpm database with information about packages from all available modules. When you install a system, the installer unpacks this main module and the set of modules chosen by user. For every module which was not installed, installed takes a list of its packages and drop information about them from the database:

rpm -e --nodeps --noscripts --notriggers --justdb foo.rpm

This is much faster and effective then per-package installation and provides enough flexibility.

In our reality, we can use the following way:

  • build a single squashfs with all necessary packages (this is done by ABF now)
  • split this squashfs to modules
  • teach the installer to install these modules.

In addition, we should take care about scripts and triggers separately - since we use '--noscripts' and '--notriggers', there is a chance that after clean up we will have some garbage left in the system. The most common case is user/group created by a package - likely we will have to just provide a list of such users/groups for every module in addition to the package list.