Using specific entries for the Option dependency tags to share information, actively, among the tools of the different WPs.

Using specific entries for the Option dependency tags to share information, actively, among the tools of the different WPs.

A preliminary description of these option tags is in the D2.1 pages 58 to 67, but it would be very important that this proposal be scrutinized by wp3 people to make sure the language is as expressive as we really need in practice.

Here is a simple use case:

i) Cooker contains some thousand packages, including a kernel K2.6.4-2 and K2.6.4-3. Some users in the testing pool discover that an error always appear when using GPhoto version 3 with K2.6.4-3 but not K2.6.4-2. After an extenuating narrowing of the bug, Mandriva engineers find out that all this comes from an obscure kernel option FUZZY_USB_HACK that was enabled in the compilation of the kernel since K2.6.4-2. This is fixed, and the new kernel K2.6.4-4 has no longer this hack enabled.

ii) this information is turned into active knowledge by the QA team by introducing a new compilation option uses_fuzzy_usb_hack for the kernel package, and entering in the QA metadata database a few lines specifying the value of this option for each of the existing kernel packages, something like

     Package: kernel
     Version: 2.6.4-3
     Compilation-option: uses_fuzzy_usb_hack

(the option is supposed to be false unless declared.)

and a few lines for gphoto

     Package: gphoto
     Version: 3
     Option-conflicts: kernel(uses_fuzzy_usb_hack)

iii) the package manager (urpmi, apt, smart, whatever) may now add as a new source the QA metadataserver that will merge the usual rpm/deb information with the new metadata from the QA database

iv) the package manager (or the testing tools we are deploying) will then solve the constraints tacking into account these additional constraints, so that installing gphoto v3 on a machine running K2.6.4-3 will now raise an error message and suggest upgrading the kernel package

v) now we continue life as before, until we discover some other interesting incompatibility.

The advantage of this approach w.r.t. adding generic new conflicts between gphoto v3 and K2.6.4-3 is that we keep our knowledge of WHY the conflict is there (where it really comes from).

In a sense, I would look at this as a new, modern way of building a knowledge base (each entry could have an Explanation: tag containing information on the added conflict, for example), much in the spirit of the "semantic web".

Ideally, we would also like to see these compilation or configuration option formally used wehn building or installing packages.

For example, if we know that tomcat conflicts with apache when apache uses port 80, we would like to have a standard tool proposing an alternative port, stright from the namespace definition for the options in apache, NOT just another shell script tailored for fiddling with the apace configuration.

Anyway, all in all, we can also just stick with the simple proposal to keep separated concerns separated, so we have a rich namespace that could go beyond the simple configuration/compilation example.

There are some issues to be addressed here:

• is the namespace described in D2.1 rich enough? For example, to avoid verbosity, we do not qualify options among compilation and configuration so we write

     Option-conflicts: kernel(uses_fuzzy_usb_hack)

instead of the more precise

     Option-conflicts: kernel(compilation:uses_fuzzy_usb_hack)

but I wonder if this will lead to problem later (in particular, looking at a conflict alone we do not know whether it is compilation or configuration related...)

• is this kind of information enough? do we need more than this? what about the way we should handle the conflicts? should we give a way to define generic conflict rules in the medatata, like

    "if a package has used the library libfoo.a version >> 3.4.1, then it will
     have problems with all kernels compiled with option uses_fuzzy_usb_hack"

and the package by package conflicts will be generated by the metadataserver by applying the rule to the package set.

I think that compilation and configuration are just two possible categories among many more possible ones, so we could try to copy some ideas from work on ontologies and be more generic, but I am non an expert on all this.

• also, we should understand whether the flexibility in the medadata server operation (replace vs append for each property), is what we want.
• is it reasonable to think that the Semantic Knowledge Base we ind of suggest might be useful in practice? How would a tool to handle uniformly configuration options be actually designed?

I think that input from other WPx is important here (for example, these kind of new relationships are natural ground for defining measures and collecting statistics).