Mailinglist Archive: zypp-devel (148 mails)

[Jan Kupec <jkupec@xxxxxxx>]

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@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx