[zypp-devel] New solver call : resolveQueue
Hi, apart from the solver call "resolvePool" ( collect all transactions from the pool, solving this transactions and writing the result back to pool) the solver can work off a given request queue too: /** * Resolve package dependencies: * * The solver works off the given queue and writes back the solution * to pool. * * Returns "true" on success (i.e., if there were no problems that * need user interaction) and "false" if there were problems. In * the latter case, use problems() and later applySolutions() * below. **/ bool resolveQueue (solver::detail::SolverQueueItemList & queue); The queue can have elements which are described in the following classes: base class: SolverQueueItem.h SolverQueueItemDelete.h SolverQueueItemInstall.h SolverQueueItemLock.h SolverQueueItemInstallOneOf.h SolverQueueItemUpdate.h Known problems: - The update and InstallOneOf request does not work correctly. - The error messages are too abstract now for the user. (Jano, you can start implementation now :-) ) Greetings Stefan -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefan Schubert wrote:
Hi, apart from the solver call "resolvePool" ( collect all transactions from the pool, solving this transactions and writing the result back to pool) the solver can work off a given request queue too:
/** * Resolve package dependencies: * * The solver works off the given queue and writes back the solution * to pool. * * Returns "true" on success (i.e., if there were no problems that * need user interaction) and "false" if there were problems. In * the latter case, use problems() and later applySolutions() * below. **/ bool resolveQueue (solver::detail::SolverQueueItemList & queue);
Can resolveQueue and resolvePool be used together? I mean, if i use a few addRequires(), then a collect a few QueueItems, then call resolveQueue() and then resolvePool()? Should pose no problem, or?
The queue can have elements which are described in the following classes:
base class: SolverQueueItem.h
SolverQueueItemDelete.h SolverQueueItemInstall.h SolverQueueItemLock.h SolverQueueItemInstallOneOf.h SolverQueueItemUpdate.h
Known problems: - The update and InstallOneOf request does not work correctly. - The error messages are too abstract now for the user.
Is this corrected by now? Esp. the update :O)
(Jano, you can start implementation now :-) )
Ouch, almost one year passed from 'now' :O) - ------------- BTW: apart from this, we will need even more rich solve API, e.g. something to: - - install specific name AND version (AND arch, AND from specific repo) - - install specific capability with specific arch, repo (version we already handle). - - plus some more - i'll try to get together a complete list. Currently zypper handles this by itself, but it's bug-prone, as things in libzypp change (e.g. priorities introduced), and the code is not shared this way. - -- 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 iEYEARECAAYFAkm1AdIACgkQgEhGpmN+6QF4MACdFi90+aCZS/xOXer0PkQFP22O S2QAn0xiWtcZ9un2SbnZ5wHggmfY3v/I =8hEP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Stefan Schubert wrote:
Hi, apart from the solver call "resolvePool" ( collect all transactions from the pool, solving this transactions and writing the result back to pool) the solver can work off a given request queue too:
/** * Resolve package dependencies: * * The solver works off the given queue and writes back the solution * to pool. * * Returns "true" on success (i.e., if there were no problems that * need user interaction) and "false" if there were problems. In * the latter case, use problems() and later applySolutions() * below. **/ bool resolveQueue (solver::detail::SolverQueueItemList & queue);
Can resolveQueue and resolvePool be used together? I mean, if i use a few addRequires(), then a collect a few QueueItems, then call resolveQueue() and then resolvePool()? Should pose no problem, or? It is a problem. You can use one way only.
The queue can have elements which are described in the following classes:
base class: SolverQueueItem.h
SolverQueueItemDelete.h SolverQueueItemInstall.h SolverQueueItemLock.h SolverQueueItemInstallOneOf.h SolverQueueItemUpdate.h
Known problems: - The update and InstallOneOf request does not work correctly. - The error messages are too abstract now for the user. As I have not changed anything since one year here. I assume that
Jan Kupec schrieb: the problems still exists. But we will have to check it again.
Is this corrected by now? Esp. the update :O)
(Jano, you can start implementation now :-) )
Ouch, almost one year passed from 'now' :O)
At least we are starting now :-)
------------- BTW: apart from this, we will need even more rich solve API, e.g. something to: - install specific name AND version (AND arch, AND from specific repo) - install specific capability with specific arch, repo (version we already handle). - plus some more - i'll try to get together a complete list.
Please send us a list. Greetings Stefan
Currently zypper handles this by itself, but it's bug-prone, as things in libzypp change (e.g. priorities introduced), and the code is not shared this way.
-- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi@suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefan Schubert wrote:
Jan Kupec schrieb:
Can resolveQueue and resolvePool be used together? I mean, if i use a few addRequires(), then a collect a few QueueItems, then call resolveQueue() and then resolvePool()? Should pose no problem, or? It is a problem. You can use one way only.
That can be problematic. The best way would be to switch completely to resolveQueue() or stick with resolvePool() then.
BTW: apart from this, we will need even more rich solve API, e.g.
Please send us a list.
Sent in a separate mail ("Some needed (zypp) solver API additions") j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkm3qZsACgkQgEhGpmN+6QG/WQCffMoP295ZANkfWfwUgZo5iwcq bvYAn0qNg62/1IEhTGxZ+d8FbtDkIUmk =kngP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
While we're asking for features, can I request that a call be added to libsatsolver that will write a repo to a solv file, as repo_write does in tools/repo_write.c? Thanks, Matt -- Matt Barringer, Software Engineer SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) http://susestudio.com http://www.novell.com/linux
* Matt Barringer <mbarringer@suse.de> [Mar 11. 2009 13:13]:
While we're asking for features, can I request that a call be added to libsatsolver that will write a repo to a solv file, as repo_write does in tools/repo_write.c?
What would be the use case for such a call ? And, more important, how would such a repo come into existance ? I currently know of three ways to create a repo in satsolver - load from .solv file - load from rpm database - manual creation (add empty repo, add solvables to this repo) Only the first two are of practical use, the last one is more for development and testing. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Wed, 11 Mar 2009, Klaus Kaempf wrote:
What would be the use case for such a call ?
And, more important, how would such a repo come into existance ? I currently know of three ways to create a repo in satsolver - load from .solv file - load from rpm database - manual creation (add empty repo, add solvables to this repo)
Only the first two are of practical use, the last one is more for development and testing.
We manually create repos as part of SUSE Studio. The use case would be us not needing to copy repo_write.c into our source tree whenever we update our copy of libsatsolver. Thanks, Matt -- Matt Barringer, Software Engineer SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) http://susestudio.com http://www.novell.com/linux
Hi, On Wed, 11 Mar 2009, Matt Barringer wrote:
On Wed, 11 Mar 2009, Klaus Kaempf wrote:
What would be the use case for such a call ?
And, more important, how would such a repo come into existance ? I currently know of three ways to create a repo in satsolver - load from .solv file - load from rpm database - manual creation (add empty repo, add solvables to this repo)
Only the first two are of practical use, the last one is more for development and testing.
We manually create repos as part of SUSE Studio. The use case would be us not needing to copy repo_write.c into our source tree whenever we update our copy of libsatsolver.
I sometimes thought about splitting the common code of tools/*.c (there's much, in particular the several XML parsing constructs) into a new libsattools library, which would also contain the repo_write stuff. Eventually I get to that when I do the static->shared lib transition. I would hope it's acceptable for you to have to link against an additional lib. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
* Michael Matz <matz@suse.de> [Mar 11. 2009 13:54]:
I sometimes thought about splitting the common code of tools/*.c (there's much, in particular the several XML parsing constructs) into a new libsattools library, which would also contain the repo_write stuff.
That would be very helpful. For the {perl, python, ruby}-bindings, I also use tools/repo_rpmdb.c to easily read the rpm database into the pool. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Wed, 11 Mar 2009, Michael Matz wrote:
I sometimes thought about splitting the common code of tools/*.c (there's much, in particular the several XML parsing constructs) into a new libsattools library, which would also contain the repo_write stuff. Eventually I get to that when I do the static->shared lib transition.
That would be perfect. Thanks, Matt -- Matt Barringer, Software Engineer SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) http://susestudio.com http://www.novell.com/linux
On Wed, Mar 11, 2009 at 01:54:34PM +0100, Michael Matz wrote:
I sometimes thought about splitting the common code of tools/*.c (there's much, in particular the several XML parsing constructs) into a new libsattools library, which would also contain the repo_write stuff. Eventually I get to that when I do the static->shared lib transition.
I would hope it's acceptable for you to have to link against an additional lib.
I don't know why the repo_* functions can't live in libsatsolver. They were always meant to be in there. I think they were excluded because they add dependencies to external libraries, but we now have repo_helix (yuck!) in libsatsolver so that reason is moot. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Hi, On Wed, 11 Mar 2009, Michael Schroeder wrote:
I sometimes thought about splitting the common code of tools/*.c (there's much, in particular the several XML parsing constructs) into a new libsattools library, which would also contain the repo_write stuff. Eventually I get to that when I do the static->shared lib transition.
I would hope it's acceptable for you to have to link against an additional lib.
I don't know why the repo_* functions can't live in libsatsolver.
(They obviously _can_, which isn't the same as _should_ :) ) I don't see a reason for e.g. repo_deltainfoxml.c, or generally all the different converters to be in libsatsolver. IMO it should consist of exactly the stuff to load SOLV files and do the solving and reporting, and nothing more. That repo_helix is in there is just an artifact of the checker program needing it. It could have linked against that other lib if it existed. My reasoning for this is my usual strive for "lean and mean". E.g. I could imagine for libsatsolver to be in a very small image that's good for installing only, and only when you get SOLV files already. I would be annoyed if that library would be bloated by useless converter or SOLV writing code. I basically don't see what should be bad about having two libraries.
They were always meant to be in there. I think they were excluded because they add dependencies to external libraries, but we now have repo_helix (yuck!) in libsatsolver so that reason is moot.
We can move it out again, once we have a place to move it to. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
* Matt Barringer <mbarringer@suse.de> [Mar 11. 2009 13:28]:
On Wed, 11 Mar 2009, Klaus Kaempf wrote:
What would be the use case for such a call ?
And, more important, how would such a repo come into existance ? I currently know of three ways to create a repo in satsolver - load from .solv file - load from rpm database - manual creation (add empty repo, add solvables to this repo)
Only the first two are of practical use, the last one is more for development and testing.
We manually create repos as part of SUSE Studio. The use case would be us not needing to copy repo_write.c into our source tree whenever we update our copy of libsatsolver.
Ah, I see. Thanks. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
participants (6)
-
Jan Kupec -
Klaus Kaempf -
Matt Barringer -
Michael Matz -
Michael Schroeder -
Stefan Schubert