Mailinglist Archive: zypp-devel (102 mails)

[Jan Kupec <jkupec@xxxxxxx>]

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

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.

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?

- --
cheers,
jano


 Ján Kupec
 YaST team
- ---------------------------------------------------------(PGP)---
 Key ID: 637EE901
 Fingerprint: 93B9 C79B 2D20 51C3 800B  E09B 8048 46A6 637E E901
- ---------------------------------------------------------(IRC)---
 Server: irc.freenode.net
 Nick: jniq
 Channels: #zypp #yast #suse #susecz
- ---------------------------------------------------------(EOF)---

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

iEYEARECAAYFAkm3p9UACgkQgEhGpmN+6QG0igCeL8AdKBNBUTDBhxCKzG/CHJsV
ADoAn2dra8hKgEV/ZNCNux/MLiLgyvfo
=JrwM
-----END PGP SIGNATURE-----
-- 
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx