Mailinglist Archive: zypp-devel (70 mails)

[Klaus Kaempf <kkaempf@xxxxxxx>]

* Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx> [Oct 31. 2007 10:51]:
> > Solver algorithms:
> > ------------------
> >
> > - the solver allows arch changes from/to noarch without complaining.
> >   good or bad?
>
> good question. noarch is supposed to work, but I am not sure if this usecase 
> really happens often. I can imagine a java package getting rid of some native 
> extension, in this case the noarch package wll be the enhanced one by the 
> package maintainer.

I'm sorry to give the usual answer (;-)): Its a policy

Opensuse customer will most probably not care at all, server admins _do_
care about _any_ package change.

> > - vendow changes are allowed from unknown to known. libzypp doesn't
> >   allow that. Feature?
>
> There are not known vendors, there are vendor changes, and current libzypp 
> behaviour is not select a different vendor in a upgrade as candidate, unless 
> it s a explicit user transaction.

Any change in vendor must be checked imho. The check should allow to
set up 'equivalence classes' though.

Vendor handling is similar to repository handling, regarding
preference. If an admin sets up a local repository, packages from this
repository should be preferred regardless of the vendor (or arch, or
whatever).

> > - arch changes are only considered if the name stays the same, so
> >   a rename can install a different architecture.
>
> bug?

Depends on the action. It shouldn't be allowed during 'normal' update
but is fully acceptable during 'dist-upgrade' (aka follow-factory)

> > - same with vendor.
>
> bug :-)

See above.

>  
> > - should prune_best_version_arch consider the arch or the vendor this
> >   is about an installed package?
>
> what does it do?

Yes, I think both arch and vendor (resp. repository) should be honored.

> > - we disable conflicting rules when searching for a suggestion, should
> >   we first extend them with arch changes/vendor changes/downgrades?
> >   In what order?
>
> I dont understand.

Actually, I wouldn't extend them. A recommends / suggests is optional.
Either it is satisfiably or its dropped.

> > - distupdate sets 'allowuninstall'. Should it only allow uninstall
> >   for packages that do not have an update in the repositories?
>
> No idea.

I guess this question is as old as Linux ;-)

> From past discussions, I remember the following:

If there is no 'upgrade candidate' for a package available, then keep the
package if none of its dependencies break (e.g. documentation, fonts,
...)
Keep all other such packages in a list and let the application handle
them.

>  
> > - splitprovides don't work at all.

Do we _really_ still need them ? How do other Linux distributions
handle this problem ? Keep in mind that 'compatibility with yum/smart
_is_ important'

> > - repo priorities should influence the order in which package rules
> >   are fulfilled.
>
> why?
>
> I think repo priorities are no more than part of the policy to select a 
> candidate. I think in tis aspect the solver should implement something 
> flexible, like a callback passing candidates and context and returning the 
> selected one, or giving each of them scores.

Exactly. Repo priorities help in selecting the candidate and also in
choosing the right repo for downloading (when multiple repos contain
the same candidate.)

> > - weak systemrules should be created for all installed packages, so
> >   that they are available when the erase rule is disabled if a
> >   suggestion is calculated.
>
> what are weak system rules? a installed rpm recommends?
>
> > - should we implement weak systemrules as weak rules?
>
> ??
>
> > - prune_best_version_arch has a n^2 loop when looking at obsoletes.
> >   Should we create an obsoletes index to speed that up?
>
> ZYpp right now has indexes for all kind of requries, and that is why it needs 
> all dependencies in the pool before solving, to build those.

Lets focus on functionality before adressing performance details.

>  
> > Code cleanup:
> > -------------
> > - move whatprovides/whatprovidesdata from pool to solver?
> >   good: can implement installed(), though I don't know if we need
>
> I wanted to implement each_installed() in the solver (ruby)

Applications need a 'show installed' view.

> >   bad: need to allocate solver if we just want to look up a provides.
> >        can't re-use whatprovides for multiple solver runs with different
> >        solvers.
>
> it can be in the pool and wrapped in the solver. The solver has access to the 
> pool but not viceversa

Looking at provides is really a detailed view in most applications.
Making application access to this data relatively slow is probably
acceptable.

> > - implement unified idarray in pool, so that repos don't have to
> >   come with their own idarrays? Would need memory for hash, but
> >   unification would be a nice thing. Would also fix solver memory
> >   leak with learned rules. Needs some hard numbers abour memory usage.
>
> No idea here.

First the hard numbers please ;-)

> > - make bitmap macros inline functions?
>
> it is ok as long as they are well documented and it the right header.
>  
> > - rename ID Macros to ID_, e.g. ARCH_NOARCH to ID_ARCH_NOARCH?
>
> Everything that makes things explicit and intutive-> principe of least 
> surprise -> is welcome.
>
> > - support different streams than FILE in repo_ functions? Is it
> >   enough that glibc supports FILE overloading, see the undocumented
> >   fopencookie()?
>
> For ruby bindings it was no problem to work with FILE. Still, I am thinking 
> of 
> the use case of an application server, where you want to load the repos once 
> in memory and share them across requests. It is a valid use case (I already 
> saw it), but I have no idea how to support this.

Klaus
---
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

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