| 1 |
W dniu wto, 13.02.2018 o godzinie 07∶49 +0000, użytkownik Martin Vaeth |
| 2 |
napisał: |
| 3 |
> Michael Lienhardt <michael.lienhardt@×××××××.net> wrote: |
| 4 |
> > |
| 5 |
> > ad-hoc fixes and tweaks that can hardly be encoded into SAT constraints. |
| 6 |
> |
| 7 |
> The main difficulty which I see is that one does not want only _some_ |
| 8 |
> solution, but among all solutions one which optimizes certain quantities. |
| 9 |
> So it seems to me that a discrete optimization under constraints |
| 10 |
> is required instead of a pure SAT solver (although formally, of course, |
| 11 |
> such an optimization problem can be reduced to SAT, I do not know whether |
| 12 |
> you went the road): |
| 13 |
> |
| 14 |
> a. The number of packages which change their status (from installed to |
| 15 |
> uninstalled or vice versa) should be minimal. |
| 16 |
> |
| 17 |
> b. Similarly, the number of USE-flag changes necessary to achieve this |
| 18 |
> aim should be minimized. |
| 19 |
> (You didn't tell whether your solver already supports such changes, |
| 20 |
> but when it is finished, it definitely should.) |
| 21 |
> |
| 22 |
> Hopefully in near future, there will be a second class of USE-flags |
| 23 |
> whose change is "cheap" which should be excluded from this minimization |
| 24 |
> restriction: |
| 25 |
> https://bugs.gentoo.org/show_bug.cgi?id=424283 |
| 26 |
> I think the main reason why nobody dared to implement them yet |
| 27 |
> (although almost everybody wants them) are exactly these implications |
| 28 |
> on the current solver in portage which nobody dares to change anymore |
| 29 |
> seriously. |
| 30 |
> |
| 31 |
> c. A solution with dependency loops should be avoided if possible |
| 32 |
> (which is why currently the PDEPEND hacks do exist: To tell the solver |
| 33 |
> which loops are not a problem.) |
| 34 |
> |
| 35 |
> d. In || ( ... ) clauses the left-most packages should be preserved. |
| 36 |
> There are similar (and more difficult) rules for REQUIRED_USE. |
| 37 |
> |
| 38 |
> e. Last but not least: The preferences are ordered a > b > c > d |
| 39 |
> (A dependency loop of uninstalled packages should probably have even |
| 40 |
> higher priority than a). |
| 41 |
> Additionally the change installed -> uninstalled should be less |
| 42 |
> "expensive" than the change uninstalled -> installed. |
| 43 |
> The correct weighting of the quantities should probably be a matter |
| 44 |
> of discussion (or preferrably even user-customizable), and preferrably |
| 45 |
> should not depend only on the number of packages but also on other |
| 46 |
> customizable quantities (e.g. the package size). |
| 47 |
> |
| 48 |
|
| 49 |
Thank you for listing this. However, I think you've missed the most |
| 50 |
important point: we want to prefer the newest version, whenever possible |
| 51 |
;-). |
| 52 |
|
| 53 |
-- |
| 54 |
Best regards, |
| 55 |
Michał Górny |
Archives