Dependency Tracking with installer / emerge

[Ralf Habacker]

Saro Engels schrieb:
> Hi all,
> I added some support for the installer's "database" system to the emerge 
> scripts today - packages that are installed with the emerge scripts can 
> be uninstalled now with the installer.
>
> Since I want to drop the simple installed package list in the emerge 
> scripts and since I want to implement an uninstall feature to the emerge 
> scripts I am currently thinking of how we can handle dependencies and 
> uninstalling with both apps.
> My idea is:
> ( Use either another file under kderoot/manifest or use the already 
> existing .ver file - last one is preferred by me )
>   
> If package A is installed that depends on package B it will add its name 
> to the .ver list;
>   
> If package A gets uninstalled the entries in all .ver files that package 
> A depends on, are removed.
>   
> If one tries to uninstall package B which is needed by some package A, 
> one can either not uninstall package B, or try to uninstall all packages 
> that need package B.
>
> Since there should be room for different behaviour in the last case, and 
> since we have at least some dependencies, we should think of a solution 
> that provides those possibilities.
>   
Since I'm not very experienced with the internals of the emerge system I
cannot say if this is a good idea, but adding and removing dependencies
dynamically in the .ver looks not good because the install state of a
package could be determined by the presence of the related ver or mft file.

Do you have thought about how dependencies should be managed in general 
  ? Dependencies are a main topic for installing/building (KDE) package on
windows and there are some more use cases which should be considered.

1. Currently we have archives without a propper package description and
dependency tracking. The emerge build system has some sort of
dependencies in the package configuration files but they are not
distributed along with the package as for example rpm does neither they
could be fetch from a given package somewhere located on the web.

2. To be able to have full dependency support for installers and build
systems a separate package descripter file distributed with the archives
is required. Placing such informations in the archive requires
unpackaging to access the package information which is very
inperformant. My proposal is to add a 'hint' file to each package (as
cygwin does with there setup.hint).

An example is shown below:

kdewin32-mingw-0.3.0-src.zip
kdewin32-mingw-0.3.0-bin.zip
kdewin32-mingw-0.3.0-doc.zip
kdewin32-mingw-0.3.0-lib.zip
kdewin32.hint

------- kdewin32.hint << -----------------------------
sdesc: "kde supplementary package for win32"
ldesc: "kdewin32 is a supplementary package with
tools/functions/definitions required by kde sources and not available on
win32"
category: kdesupport
requires-mingw: qt-mingw  -> mingw dependencies  (this is an extension
to the cygwin setup.hint file)
requires-msvc: qt-msvc      -> msvc depenedencies  (this is an extension
to the cygwin setup.hint file)
requires: libpng zlib             -> general dependencies
------- >> kdewin32.hint -----------------------------


a cygwin compatible directory structure would be also possible

directory kdewin32/
    kdewin32-mingw-0.3.0-src.zip
    kdewin32-mingw-0.3.0-bin.zip
    kdewin32-mingw-0.3.0-doc.zip
    kdewin32-mingw-0.3.0-lib.zip
    setup.hint

where setup.hint contains the same text as the kdewin32.hint above.

The emerge build system could fetch the hint files directly for
dependency tracking and other usefull information along with the archives.

installers could use the hint files directly or a collected version of
the hint files (as we have with the config.txt now).
The collected config file could be created by a kind of site management
tool (which is in work). The Installer will then be available to track
dependencies and display detailed package description. This would help
also for cd releases.

Any comments ?

Ralf