Mailinglist Archive: zypp-devel (70 mails)
|< Previous||Next >|
[zypp-devel] sat solver enhancements and questions
- From: Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx>
- Date: Fri, 26 Oct 2007 13:32:26 +0200
- Message-id: <200710261332.26896.dmacvicar@xxxxxxx>
I have been playing with the sat solver motivated by being able to use it from
ruby scripts or rails apps, and also to familiarize myself with the internals
I have in my local git a patch that adds the following:
- beatiful ruby bindings (and 99% of the stuff needed to have perl, python,
- cmake build support
The bindings look like this right now:
pool = Pool.new
s = pool.add_source_solv(f, 'foo')
installed = pool.add_source_solv(f, 'system')
pool.each_source do |repo|
s.each_solvable do |r|
q = Queue.new
r = pool.select_solvable(s, 'gnome-desktop')
# push one command and one resolvable to the queue
pool.promoteepoch = true
solv = Solver.new(pool, installed)
solv.fixsystem = 0
solv.updatesystem = 0
solv.allowdowngrade = 0
solv.allowuninstall = 0
solv.noupdateprovide = 0
# solve the queue
As you can see, lot of the not-nice-things of the current API are hidden, so
humans can use it. For example:
- Queue push automatically knows if you are passing a command or a solvable,
and does that offset calculation by itself
- iterations of pool solvables or pool sources made easy with ruby each
- Convertion of ruby File to C FILE*
What is missing in the bindings part:
- translation of attributes like name from Id to string in a transparent way
(the fact that the conversion function needs a pool is my limiting factor
- fixing of attributes names to follow ruby conventions.
What can be enhanced in the C api:
- choose conventions. Come on, this is not something technical, just some
discipline that helps people. I dont think having one method called
pool_something and then other called queuesomething makes sense except to
annoy.. The convention class_action( class*, args ) is pretty standard in C
OO code. Use it, but don't mix or you make people have to read the code to
guess method names.
- Source name. It was very difficult to standarze the name in libzypp, product
management and other products to repositories. Calling it Source is going
back to 10.2 and introduce more confusion. The official word is repo now, why
not use it?
- there is a bug when you add a empty system repo to the solver, it segfaults.
- I had some trouble wth the bool stuff (typedef _Bool bool) and swig
For the cmake part:
- It supports out of source tree build by definition, and this is nice if you
are using git
- it does everything, except if I am missing some coolo's requirement needed
to run the testsuite.
- it supports packaging, and check svn if there are uncommited stuff before
- the ruby bindings require the cmake build. It took me 5 minutes to do
everything wth cmake, but 20 minutes looking for autocrap swig macros.
- I havent tested building the package and spec, but it is there.
I have no problem to maintain the cmake part (even in paralell), unless
everyone loves it and it can be made the default. it is ok to commit it?
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
|< Previous||Next >|