
	links to this page:

DepS dependencies

Last updated at 12:23 pm UTC on 28 August 2004

from Stephan Rudlof

Under Construction!

History

version	date	comment
0.6	28.8.04	Install package example: delete of upgraded package added in graphics
0.5	27.8.04	corrections and improvements term Transformation replaced by Rule
0.4	26.8.04	Install package example
0.3	26.8.04	corrections
0.2	15.8.04	Technical stuff Dependencies table for package installation
0.1	11.8.04	Dependencies table

Dependencies table

name	semantics	question to the maintainer wanting to express a dependency
pre-requirement	needed before some action, not removable thereafter	"Do you want to express a requirement needed before some action at package changing time? It must not be removed thereafter without breaking something."
post-requirement	needed after some action, temporarily removable during package changing time	"Do you want to express a requirement needed after some action at package changing time? It can be temporarily removed during package changing time without breaking something, but has to be there at run time. E.g. your package needs another one at run time, which may be installed after it."
action-requirement	needed only for time of some action	"Do you want to express a requirement needed only while performing some action? It may be removed immediately after performing the action and hasn't to be there again (e.g. an installer not needed at run time)."
pre-conflict	to be removed before some action, not allowed thereafter	"Do you want to express a conflict to be removed before performing some action? It has to be avoided thereafter for not breaking something."
post-conflict	to be removed after some action, temporarily allowed during package changing time	"Do you want to express a conflict forbidden after package changing time? It can temporarily arise during package changing time without breaking something, but has to be avoided at run time. E.g. your package conflicts with another package at run time, but not during installation."
action-conflict	to be avoided only while performing some action	"Do you want to express a conflict forbidden only while performing some action? It may arise again immediately after the action and may stay forever then (e.g. some property hindering install)."
pre-provide	provide is valid for performing another action, after performing action, if pre-reqirements are fulfilled, and if pre-conflicts are avoided.	Question "Do you want to express a pre-provide?" is not needed, since it will be derived from the package info.
post-provide	provide is valid at run time, after performing action, if pre- and post-reqirements are fulfilled, and if pre- and post-conflicts are avoided.	Question "Do you want to express a post-provide?" is not needed, since it will be derived from the package info.

Technically these dependencies have not to be modeled directly after this table:

It makes sense just to work with (pre-) requirements/conflicts and to model the post- ones by introducing two stages of dependency Rules. E.g. in case of installation the first stage is for providing the install requirements and triggering the install Action (possibly preceeded by installs of its requirements), the second one for providing the run requirements without triggering any Action (logical Rule).
As a further simplification Action requirements/conflicts could be put into requirements/conflicts: it should be OK to enforce the existence of e.g. an installer forever. If Action requirements/conflicts should be needed later (not probable), they could be added; but I think it's best first to prefer a more simple working solution against the most general not working one (the algorithms already will be complicated enough, AFAICS)...

These steps together are reducing the table entries from 8 to just 3 for dependency Rules: left are just requirements, conflicts and provides for each of the Rules. Isn't that nice?

Dependencies table for package installation

first question	second question	name	semantics	technical realization
"Do you want to express a requirement?"	"Is it needed before installing your package? It must not be removed thereafter without breaking your package."	install requirement	requirement needed before install, not removable thereafter	requirement in installation Rule
	"Is it needed only while installing your package? It is just needed for the time of installing your package, may be removed immediately after the action and needn't to be there again (e.g. an installer not needed at run time)."	action requirement	requirement needed only for time of Action	requirement in installation Rule
	"Is it needed after installation of your package? It can be temporarily removed during package changing time without breaking your package, but has to be there at run time. E.g. your package needs another one at run time, which may be installed after it."	run requirement	requirement needed after installation, temporarily removable during package changing time	requirement in logical Rule
"Do you want to express a conflict?"	"Has it to be removed before installing your package? It has to be avoided thereafter for not breaking your package."	install conflict	conflict to be removed before installation, not allowed thereafter	conflict in installation Rule
	"Is it forbidden only while making something with your package? It has just to be avoided for the time of making something with your package, which may arise again immediately after the action and may stay forever then (e.g. some property hindering install)."	action conflict	conflict to be avoided only for time of Action	conflict in installation Rule
	"Is it forbidden after package changing time? It can temporarily arise during package changing time without breaking your package, but has to be avoided at run time. E.g. your package conflicts with another package at run time, but not during installation."	run conflict	conflict to be removed after installation, but temporarily allowed during package changing time	conflict in logical Rule
"Do you want to express a provide?" This question is not needed, since it will be derived from the package info.		install provide	provide is valid for changing other packages, if install reqirements are fulfilled, and if install conflicts are avoided	provide in installation Rule
		run provide	provide is valid at run time, if install and run reqirements are fulfilled, and if install and run conflicts are avoided.	provide in logical Rule

Technical stuff

Install package example

Runnable_WebBrowserExtended is the target to be made, it has no number, so the user wants a Runnable_WebBrowserExtended in an arbitrary version with whatever CC.
In the graphics the install dependencies of 3 packages are shown:

"SocketStuff v1.3",
"WebBrowser v2.1", and
"WebBrowserExtended v2.0"

are the packages to be installed to get the target.
A dependency Rule in the graphics consists of

requires (written at the upper left corner of an Action): mostly they are truncated Caps,
an Action (rectangle with rounded corner), and
provides (rectangle with hard corner).

Uploaded Image: rulesForInstallationExample.png

Notes

'Real' installation is made in the upper area above the horizontal line, a logical rule without a real Action comes thereafter.
"Action: install WebBrowserExtended v2.0" is an incremental install, requiring Caps "Installed_WebBrowser 1.4.2" to be allowed. Here it is provided by "Action: install WebBrowser v2.1" providing Caps "Installed_WebBrowser 1.4.2.2.1.1", but another one with a higher CC could work, too. The same applies for every require.
Target Runnable_WebBrowserExtended means, that every WebBrowserExtended is sufficient for making it (same as Caps "Runnable_WebBrowserExtended 1").