[Installit-dev] "package manager " becomes "InstallIt"

[Benedikt Meurer]

Jannis Pohlmann wrote:
>>The problem with this attempt was, that it doesn't integrate easily with 
>>every packaging system. So, on a second thought, I'd suggest to ask the 
>>user whether he wants to use a packaging system on first startup, e.g.
>>
>>  (*) RPM
>>  ( ) DEB
>>  ( ) Solaris Package Management
>>  ( ) BSD Package Management
>>  ( ) Custom installation prefix: [____________]
>>
>>You can easily autodetect the available package management system and 
>>preselect it:
>>
>>  1. If pkgadd is available, select "Solaris Package Management"
>>  2. If pkg_add is available, select "BSD Package Management"
>>  3. If dpkg is available, select "DEB"
>>  4. If rpm is available, select "RPM"
>>  5. Select "Custom installation prefix" and default to "/usr/local" if 
>>writable, else fallback to "$HOME/local"
>>
>>There are some systems missing from the above list, which may be added 
>>later (e.g. Darwin Ports, Gentoo Package Management, Lunar Package 
>>Management or Win32/Cygwin). In general the package/installation backend 
>>should be kept modular and easy to extend/exchange, with a well defined 
>>API implemented by the various backends.
>>
>>So, if for example, the user selects "RPM", InstallIt will query the 
>>settings from the local RPM system (sysconfdir, prefix, etc.) and use 
>>that. If the user selects "DEB", InstallIt will use the hardcoded values 
>>from the Debian Policy (sysconfdir is "/etc", prefix is "/usr", etc.). 
>>For "Solaris Package Management", prefix will be "/usr/local" or 
>>"/opt/i2t", preferrably "/usr/local". For "BSD Package Managment" prefix 
>>will be set to whatever pkg basedir is selected (usually "/usr/local" 
>>for Free/OpenBSD/DragonFly, "/usr/pkg" for NetBSD) by parsing the 
>>make.conf/mk.conf.
>>
>>Of course, binary packages can only be installed if the appropriate 
>>package management system is selected: E.g. I can only install .rpm's if 
>>I selected "RPM" earlier, likewise I can only install .tgz's/.tbz's if I 
>>selected "BSD", and so on.
> 
> 
> Thanks, those information are a great help.
> 
> Do you think of building binary packages out of all source packages when
> the user selects RPM or something like that on startup? So no source
> installation into the system, just building packages suitable for the
> platform and install them? Your words make me guess so, but that will be
> difficult since we'd have to look into all package management formats, then.

Exactly. So to the user it should not matter whether a binary package is 
available or not (well, except that building source requires -devel 
packages, but that's another story).

If you install from source, after the "make install" step is done, the 
package backend will be asked to register the installed package with the 
package management system.

Then, if the user selects uninstall, InstallIt will ask the package 
backend to uninstall the package from the system (e.g. using 
pkg_deinstall, pkg_delete, dpkg -P, rpm -e, ...).

It looks like a lot of work, but it's really trivial for most of the 
systems (e.g. on Debian systems, you basicly add your files for 
/var/lib/dpkg/info/ and a note to /var/lib/dpkg/status and you are done, 
etc.). I can write the backends for the 4 systems mentioned above. The 
important thing - as mentioned already - is to define a good API for the 
package backends, which covers everything we need to be platform 
independent.

There are several things that will need to be done for binary and source 
packages, and for source-only installation, which will need to be addressed:

1) When installing new MIME types, you'll need to call 
update-mime-database on the mime directory after installation and after 
removal of the package. There are several ways to address this problem, 
and each has disadvantages.

2) Same for the .desktop files, where you'll need to call 
update-desktop-database.

3) For icons, you'll need to call gtk-update-icon-cache on the themes to 
which new icons where installed to (hicolor in most cases), and same on 
removal.

These and other points make me think, that it might be a good idea to 
turn the source-only variant into a "pseudo package management system", 
which will also implement the above API. So, from the upper layers (i.e. 
the GUI), you use solely the backend API to "communicate with the 
underlying system".

> Regards,
> Jannis

Benedikt