Mailinglist Archive: zypp-commit (266 mails)

< Previous Next >
[zypp-commit] r11682 - /trunk/sat-solver/src/DISCUSS
  • From: mlschroe@xxxxxxxxxxxxxxxx
  • Date: Fri, 14 Nov 2008 13:29:11 -0000
  • Message-id: <20081114132911.69BBA3A220@xxxxxxxxxxxxxxxx>
Author: mlschroe
Date: Fri Nov 14 14:29:11 2008
New Revision: 11682

URL: http://svn.opensuse.org/viewcvs/zypp?rev=11682&view=rev
Log:
- delete a couple of solved points

Modified:
trunk/sat-solver/src/DISCUSS

Modified: trunk/sat-solver/src/DISCUSS
URL:
http://svn.opensuse.org/viewcvs/zypp/trunk/sat-solver/src/DISCUSS?rev=11682&r1=11681&r2=11682&view=diff
==============================================================================
--- trunk/sat-solver/src/DISCUSS (original)
+++ trunk/sat-solver/src/DISCUSS Fri Nov 14 14:29:11 2008
@@ -8,32 +8,12 @@
- vendow changes are allowed from unknown to known. libzypp doesn't
allow that. Feature?

-- arch changes are only considered if the name stays the same, so
- a rename can install a different architecture.
-
-- same with vendor.
-
- should prune_best_version_arch consider the arch or the vendor this
is about an installed package?

-- we disable conflicting rules when searching for a suggestion, should
- we first extend them with arch changes/vendor changes/downgrades?
- In what order?
-
-- distupdate sets 'allowuninstall'. Should it only allow uninstall
- for packages that do not have an update in the repositories?
-
-- splitprovides don't work at all.
-
- repo priorities should influence the order in which package rules
are fulfilled.

-- 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.
-
-- 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?


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

< Previous Next >
This Thread
  • No further messages