On Mon, Nov 27, 2017 at 3:44 PM, Michael Orlitzky <[email protected]> wrote:
> On 11/27/2017 03:37 PM, Arve Barsnes wrote: > > > > Sounds kind of weird? If he has keyworded the game package, shouldn't it > > just never install that version if it depends on an unstable package? > > That's right, but if there are two available ~arch versions, one of > which has all stable dependencies and (the newer) one of which has all > ~arch dependencies, then portage will try to install the newer one and > tell you to keyword a million things -- even though it could install the > first one with less hassle. > > In theory the resolver could support such a scheme, no? Currently it prefers "best_visible" where best == "highest version" But other predicates might be possible like "tightest_visible" Note that currently best_visible is fairly straightforward to implement: visible = find_all_visible() best_visible = max(visible) # simple ver_cmp tightest_visible: visible = find_all_visible() tightest_visible = min(visible, key=cpv.tightness) # A weird predicate where 'tightness' implies dependencies are already visible? I can't think of a better term. def tightness(self): return len([atom for atom in self.dependencies if atom.is_visible()]) So "tighter" packages have dependencies that are visible / installed. "Loose" packages have unmet dependencies or dependencies that are not currently visible. I have not messed with the portage resolver in some time; in theory given perfect code you just plum this in once.... but I'm skeptical its that easy (and I suspect best_visible is in fact 'presumed' in many places. But Zac would probably know best. -A > For example, if you're on a system with no ruby packages, then it's the > difference between having to keyword 10 packages for rails-x.y.z versus > 200 packages for rails-x.y.(z+1). I'd rather have the slightly older > version that requires less configuration. > > >
