Duncan Mac-Vicar Prett wrote:
What I would like to see improved is the code to inject transactions. think zypper has lot of useful code. The part where it _is_ boring to iterate because unlike commit, each application has to reinvent the wheel, is to set a transaction.
This is half true and half false. The difference is between the GUIs/TUIs and the CLI. The extra code you see in zypper is really needed in zypper only. Here is why: the addRequires(Capability("foo-string")) and addConflicts() is very close to make injecting of transactions a breeze, but there are two major issues with the current API: 1) CLIs need to do a lot of preprocessing to create the Capability themselves (not such a big deal in GUIs and TUIs) 2) The ResolverProblem API lacks access to some information like the type of the problem: - requirement not fulfilled: - user injected (package not found) - required via dependencies (real dependency problem) - addConflict causes no dependency problem (package not installed) And the above really applies (well.. almost) only to CLIs, it happens in GUIs only by programming error, not by user input: - you won't get malformed user input in GUI for which package to install or remove (point 1) - you won't get 'specified package not found' in GUI (point 2) - you won't get 'specified package not installed (point 2) So when thinking of a more convenient API we need to think of the differences between the types of UIs and provide API for all that we can think of (for now CLI and GUI/TUI). so zypp::install(string) { // processing pool.addRequires(Capability(...)); } would always get nice name from GUIs but would need to do the parsing stuff for CLI (with a defined syntax). Also there would have to be zypp::install(Capability) for GUIs to pass exact machine values from their lists and maps when needed. the same for e.g. zypp::lock(string) { // processing Locks.addLock(whatever) } zypp::lock(Capability); and so on for remove, update, reinstall, unlock, keep, etc...
Unlike the example above when setting a transaction, you can have nonexistent objects, or strings, so iterating over the pool to find a package and mark it for installation, is duplicated code, instead of
Oh yes, this is what i described in more detail above. I just don't see where is the code duplicated right now. But on the second thought these situations should probably be expected also when the machines (or users through the machines - GUI) do the input. E.g. requesting non-existent object (if you wanted to avoid to do query before requesting and just want to see what happens) this would apply to e.g. a script.
using the code zypper has to install by name, capability, etc. So We should really move that code to some libzypp namespace and allow for zypp::install("foo") (and document really well what does this do exactly).
Agreed. Cheers, jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org