Mailinglist Archive: zypp-devel (102 mails)

[Jan Kupec <jkupec@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Kupec wrote:
> Hi!
>
> I've put together the following list of things that would be nice to
> have in libzypp API. These are needed by command line apps like zypper
> or ruby/python scripts using the bindings, since they typically do not
> select packages to install by pointing at one particular package from a
> list of available (GUI/TUI way), but rather by package name or
> capability plus some preferences like repo, arch, version.
>
> Also, because of this, a command line app either needs a feedback from
> solver about the requested operation, or it needs to get a clue whether
> the operation will succeed in advance.
>
> Example:
> either:
> request to install package with given name, solve, get feedback from
> solver that the package is already installed, tell the user
> or:
> check whether the best package is already installed (no update candidate
> is available), and either tell the user it already is, or tell the
> solver to install it.
>
> More complex example would be bnc #482307: there is a higher version of
> a package available, but in repo with lower priority. In GUI, if you
> wondered why it does not upgrade a package, you could check the Versions
> tab, and you could click to choose the version. In CLI, e.g. when you do
> 'zypper up foo' it should tell you "no update candidate for foo found"
> plus a hint "foo x.y.z is available in repository 'bar' which has
> priority X. Use 'zypper in foo-x.y.z' or whatever to install that
> package.". The following could help.
>
> The list: (notes below)
> ---------
>
> a) install package with given name (1), plus optionaly:
>   - enforce specific version (2)
>   - enforce specific repo    (2)
>   - enforce specific arch    (3)
>   - force the operation: if appropriate package is already installed,
>     reinstall it, considering given version/repo/arch preferences
>     (meaning even if specified version is already installed, reinstall;
>     evein if better version that the specified is installed, downgrade;
>     etc - we should before make a list of all cases before
>     implementing).
>
> b) install pacakge with given capability, plus optionaly:
>   - enforce specific version (we have this)
>   - enforce specific repo
>   - enforce specific arch (4)
>   - force the operation (like above)
>
> c) update package with given name (7), plus optionaly:
>   - enforce specific repo
>   - adjust update policy (vendor change, arch change, etc.)
>
> d) find the best package with given name (5)
>    - plus the options available in a)?
>
> e) find update candidate for given installed package having the same
>    arch, plus optionally:
>   - having any compatible arch
>   - from specified repo
>   - regardless of priorities
>   - regardless of vendor
>   - maybe other policies
>
> f) Install srcpackage _without_ build deps (6)
>    - with specified version
>    - from specified repo
>
> g) Remove a package by name (8)
>    - plus enforce specific version (for multiversion packages)
>
> h) Remove a pattern
>    - needs to be defined - could be something like
>      remove all packages required[/recommended/suggested] by the
>      pattern.

i) Install a pattern
   - with recommended packages (default)
   - with suggested packages
   - in case the pattern is already satisfied, select not yet
     installed packages recommended/suggested by the pattern
     for installation

This could be used by both CLIs and GUIs (bnc #432562 + probably bnc
#476965).

j.

> If a), b), c), f), g) are provided, d) and e) are needed as the hint, to
> give the user feedback.
>
> Anything else? If you agree to have these in libzypp, i'd like to help
> implementing them, of course, since this is quite a lot of work but it
> would move the burden from zypper to libzypp. But more than that, it
> would allow to add these to libzypp testsuite, and it would make the
> functionality available to ruby/python via bindings.
>
> Notes:
> (1) Currently zypper chooses the best package by itself and does
>     ResStatus::setToBeInstalled(zypp::ResStatus::USER). It could use
>     The new solver API (SolverQueueItemInstall + resolveQueue(), but
>     that currently lacks the other capabilities - forcing
>     arch/version/repo, and one has to be carefull not to mix
>     resolvePool() and resolveQueue()).
> (2) Currently zypper needs to do this by itself
> (3) Currently zypper would need to do this by itself (not implemented)
> (4) Currently zypper appends .arch to the capability name to do this
> (5) Something like Selectable::candidate(), but that's rather GUI/TUI
>     specific. We need also a method that would return the best no matter
>     what is already "transacting" or installed.
> (6) Currently it automatically drags the build deps in, apps need to use
>     ZYpp::installSrcPackage(srcpkg)
> (7) Similarly like in (1), SolverQueueItemUpdate could be enhanced?
> (8) SolverQueueItemRemove seems to do this, but does not allow
>     to choose name/capability, and version.
>
> BTW: do we have a list of solver policies somewhere (else than the
> satsolver source code :O) and a list of possible ways to change them?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkm/43kACgkQgEhGpmN+6QFRXwCeO4XapWhi+6HDaZheGSJ76WlZ
xLYAnA5PKh6V6jH2hcA6hJkXWhdeBFjS
=cpdd
-----END PGP SIGNATURE-----
-- 
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx