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