[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] NEWS item for games destabling
From:       Alec Warner <antarus () gentoo ! org>
Date:       2017-11-27 20:55:26
Message-ID: CAAr7Pr-qi-rW7JR9JWLsgU-EHxv=7Qf-Eq9Xm2Gap=Z=p_GV5g () mail ! gmail ! com
[Download RAW message or body]

On Mon, Nov 27, 2017 at 3:44 PM, Michael Orlitzky <mjo@gentoo.org> 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.
>
>
>

[Attachment #3 (text/html)]

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



[prev in list] [next in list] [prev in thread] [next in thread]