* Stefan Schubert
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@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org