Mailinglist Archive: zypp-devel (148 mails)

["Duncan Mac-Vicar P." <dmacvicar@xxxxxxx>]

Klaus Kaempf wrote:
> Because it should hide the actual implementation of 'pool' or how
> solvables and their state are stored internally.
>
> Remember that long-term we want zypp to be 'transaction-based',
> removing the need of a huge, static, in-memory, mutex-protected data
> structure holding global state information.
>   
I think you are mixing to different things.

Pool actually does not show any implementation detail on how solvables
are stored. Actually, Pool is an abstraction on top of the sat solver
pool, which has a completely different model even for statuses (job based).

Pool by itself is a transaction. Pool represent the current transaction.
The fact that you can't use the memento pattern to snapshot it and
re-apply it does not mean we are not transaction based (and I think that
would be tricky, but not impossible to implement)

I think the only thing that is missing is an easier way to iterate the
transaction (I will start calling the pool transaction since today, to
use the new buzz) in order to do something useful with it:

like:

Pool.each do s
   if s.isToBeInstalled do foo
  if s.isToBeDeleted do bar
end

to

Pool.each_to_install do s
  do foo
end
Pool.each_to_delete do s
  do bar
end

If you see, it is only syntax sugar. What the solver returns from
solving is exactly a transaction, which are all statuses on the pool set
by user plus the ones set by solver, so I won't start mixing models,
that would only confuse people, but see where the APIs make sense to be
enhanced (for example, I am not convinced on the example above, it may
be cool for python/ruby which have an each construction but in c++ does
not make much difference )

So, the current transaction needs always to apply to some living
objects. A transaction object need to refer to a package pointer. There
either you use the ids (that would make snapshoting the current pool
state piececake) or you allow for more highlevel constructions like
"kdelibs3", which is no longer a transaction, because if the world
changes, that transaction item is no longer valid. You can use strings
for jobs (input), but not for the result, because is the solver who
needs to tell you exactly which one is to be installed. So a Transaction
class alone, would be just a collection of pairs refering to some living
object, and what to do with them, and you can get that from the pool
(the API to do that could be enhanced for sure).

Duncan
-- 
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx