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

[Jannis Pohlmann]

Benedikt Meurer schrieb:
> 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.

Okay, would be great if you could develop this API (if you have the time
to do it) and some of the backends. You seem to have higher knowledge
regarding this topic than I or Johannes.

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

Sounds like a good way for me.

- Jannis