-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pacho Ramos wrote: > El lun, 02-03-2009 a las 13:01 -0800, Zac Medico escribió: >> || ( ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) x11-libs/qt:4 ) >> >> It's a variation of bug 161953 [1]. For this particular variation, >> at the moment I don't think there's a good way to distinguish that >> the choice on the left is the better choice. > >>From my point of view, I think that portage should do something like > calculating how much a dep is already in the system, for example, in > this case, I have 50% of ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) > already installed on my system while 0% of x11-libs/qt:4. Then, > ( x11-libs/qt-gui:4 x11-libs/qt-webkit:4 ) would be a better option > because, hopefully, a user that has already installed a portion of this > dep, will prefer to maintain it installed > > But, this is only theoretical as I am not a programmer and I don't know > if this could be implemented
You're right. It's easy to says it in words but if you tried to actually implementing you'd find that the PROPERTIES=virtual concept simplifies the problem a lot and makes it possible to optimally solve some cases of bug 141118 that couldn't otherwise be solved optimally without the information that PROPERTIES=virtual provides. What we're talking about is a cost calculation and in order for the cost calculation to be as accurate as possible, we need to know which ebuilds have zero-cost to install (the virtual ones do not install anything directly so they are considered to have zero-cost in themselves). If you consider all ebuilds to have equal cost then your calculation won't be as accurate as it could be. Knowing which ebuilds are virtual gives a hint to the resolver that it should perform a "lookahead" in the cost calculation. We could implement a similar lookahead mechanism for non-virtual ebuilds, but it's more useful for the virtual ones. Backtracking (which isn't implemented yet but is planned for bug 1343) would also be useful for implementing additional cost optimizations (like the one for bug 260225). - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmthAwACgkQ/ejvha5XGaP0WwCgkpqDyXQTKRbrBU9ncvfmOIoo UlwAoOmIu1RCt7/wfSgTrMDCCx8t6IcP =CVC5 -----END PGP SIGNATURE-----
