Mailinglist Archive: zypp-devel (57 mails)
| < Previous | Next > |
Re: [zypp-devel] SAT solver testsuite, Meeting minutes
- From: Klaus Kaempf <kkaempf@xxxxxxx>
- Date: Mon, 21 Jan 2008 16:25:37 +0100
- Message-id: <20080121152537.GA23496@xxxxxxxxxxxxx>
* Stefan Schubert <schubi@xxxxxxx> [Jan 21. 2008 10:34]:
Michael Schröder (mls), Stefan Schubert (schubi) and I (kkaempf)
discussed these items today, as follows:
The error messages is misleading and should read
do not _ask to_ install a solvable providing notavailable
(A requirement, seen from the solvers perspective, is a rule asking to
install a solvable providing 'notavailable'.)
Generally, problems reported by the solver should be indentified by
enums and its up to the application layer to provide user readable
(and translatable) text. The application layer is separate from the
solver implementation but will be available in the same package.
For now, these tests will be disabled.
We agreed that handling such dependencies needs special consideration.
It does not make sense to compute and honor language dependencies in
every solver run.
This should be restricted to the following scenarios:
- the list of to-be-supported languages was changed by the user
- a new repository was added
In both cases, the application should ask the user to 'look for
additional packages' (i.e. drivers, updates, translations, etc.)
Thats a bug, mls will look into it.
kkaempf is currently working on prototyping these semantics using the
sat-solver swig bindings. Ideally, a 'transaction history' database is
available tracking the installed packages when the user selected the
pattern. Its this set of packages to be deleted when the user chooses
to remove the pattern.
The semantics of patterns and patches overlap to a great degree.
kkaempf will take patches into account in his prototyping work.
Schubi will ask Coolo (for OpenSUSE) and Kukuk (for SLE) for a
definition.
We came to the conclusion that "ignore" is the wrong notion, but
"don't care install (remove) anyway" better reflects the users
intention. Mls will implement this solution option.
Additional topics discussed:
- We need a better test coverage for sat-solver.
kkaempf will start testcases for every defined problem and every
possible solution. We will use the Ruby swig bindings as they're
better approachable than deptestomatics XML syntax.
- Application layer in sat-solver
The current sat-solver API is too 'raw' for direct use by
applications. We will provide an abstraction layer for application
developers.
(Remark: Thats indenpendant of the proposed zypp application layer
and covers sat-solver only. Synergies should be used, however.)
- How to track user decisions ?
(This is more for the zypp application layer).
Its a general question how to track user intentions when e.g. a
proposed package is de-selected.
Should this package be proposed again ? When ?
Should a similar package be proposed for another repository ? In
another version ?
- System solvable in sat-solver
The 'system' solvable in sat-solver is purely internal and will NOT
be available at the API (swig) layer.
Driver (modalias) and language (locale) dependencies will be handled
by the application layer. It will create a dummy repo with solvables
issuing proper dependencies. This should also ease relating problems
to driver or language dependencies.
- Boolean expressions in dependencies
The boolean dependency operators 'and', 'or' and 'with' have
limitations. mls will document them.
Short version: 'and' can only be used for supplements since no rules
are generated for this. 'and' cannot be used within Requires or
Conflicts.
Klaus
---
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
Hi,
I have gone through the testcases and following items are currently missed:
Michael Schröder (mls), Stefan Schubert (schubi) and I (kkaempf)
discussed these items today, as follows:
- "Require <name>" request.
If the requirement cannot be fulfilled this missleading error message
will be shown:
< Encountered problems! Here are the solutions:
<
< Problem 1:
< ====================================
< nothing provides requested notavailable
<
< - do not install a solvable providing notavailable
The error messages is misleading and should read
do not _ask to_ install a solvable providing notavailable
(A requirement, seen from the solvers perspective, is a rule asking to
install a solvable providing 'notavailable'.)
Generally, problems reported by the solver should be indentified by
enums and its up to the application layer to provide user readable
(and translatable) text. The application layer is separate from the
solver implementation but will be available in the same package.
- If the user installs an addition language ( in an installed system )
the concerning language packages will not be installed.
For now, these tests will be disabled.
We agreed that handling such dependencies needs special consideration.
It does not make sense to compute and honor language dependencies in
every solver run.
This should be restricted to the following scenarios:
- the list of to-be-supported languages was changed by the user
- a new repository was added
In both cases, the application should ask the user to 'look for
additional packages' (i.e. drivers, updates, translations, etc.)
- Additional kernels will be installed although there is already an
installed kernel available. (e.G.: ./bugzilla-tests/bug208784-test.xml)
Thats a bug, mls will look into it.
- Currently there is no functionality when a pattern will be deleted.
(What should happens with the concerning packages ?)
kkaempf is currently working on prototyping these semantics using the
sat-solver swig bindings. Ideally, a 'transaction history' database is
available tracking the installed packages when the user selected the
pattern. Its this set of packages to be deleted when the user chooses
to remove the pattern.
- Patch handling has to be completed.
The semantics of patterns and patches overlap to a great degree.
kkaempf will take patches into account in his prototyping work.
- Vendor handling has to be solved/defined.
(e.G.: bug310455-test.xml)
Schubi will ask Coolo (for OpenSUSE) and Kukuk (for SLE) for a
definition.
- The solutions do not have an "ignore" options.
We came to the conclusion that "ignore" is the wrong notion, but
"don't care install (remove) anyway" better reflects the users
intention. Mls will implement this solution option.
Additional topics discussed:
- We need a better test coverage for sat-solver.
kkaempf will start testcases for every defined problem and every
possible solution. We will use the Ruby swig bindings as they're
better approachable than deptestomatics XML syntax.
- Application layer in sat-solver
The current sat-solver API is too 'raw' for direct use by
applications. We will provide an abstraction layer for application
developers.
(Remark: Thats indenpendant of the proposed zypp application layer
and covers sat-solver only. Synergies should be used, however.)
- How to track user decisions ?
(This is more for the zypp application layer).
Its a general question how to track user intentions when e.g. a
proposed package is de-selected.
Should this package be proposed again ? When ?
Should a similar package be proposed for another repository ? In
another version ?
- System solvable in sat-solver
The 'system' solvable in sat-solver is purely internal and will NOT
be available at the API (swig) layer.
Driver (modalias) and language (locale) dependencies will be handled
by the application layer. It will create a dummy repo with solvables
issuing proper dependencies. This should also ease relating problems
to driver or language dependencies.
- Boolean expressions in dependencies
The boolean dependency operators 'and', 'or' and 'with' have
limitations. mls will document them.
Short version: 'and' can only be used for supplements since no rules
are generated for this. 'and' cannot be used within Requires or
Conflicts.
Klaus
---
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
| < Previous | Next > |