<div dir="ltr">Hi<div><br></div><div class="gmail_extra"><div class="gmail_quote">On Sun, Aug 6, 2017 at 6:43 PM, Jackson Isaac <span dir="ltr"><<a href="mailto:ijackson@macports.org" target="_blank">ijackson@macports.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On Sun, Aug 6, 2017 at 5:41 PM, Umesh Singla <<a href="mailto:umeshksingla@macports.org">umeshksingla@macports.org</a>> wrote:<br>
> On Sat, Jul 22, 2017 at 7:26 AM, Joshua Root <<a href="mailto:jmr@macports.org">jmr@macports.org</a>> wrote:<br>
>><br>
>><br>
>>> For now, I'd like to ask in what order does "registry::entry imaged"<br>
>>> returns the port list? Because I'm running the sorting function which the<br>
>>> restore_ports.tcl uses but it's giving me the ports in the same order as<br>
>>> result.<br>
>><br>
>><br>
>> Probably just ordered by rowid, i.e. might as well be random. Note that<br>
>> the sort_ports proc from restore_ports.tcl does not take a list of registry<br>
>> references like registry::entry returns, but a list of strings representing<br>
>> port names, versions and variants in the format generated by 'port<br>
>> installed'.<br>
><br>
><br>
> `port installed` returns the result of `registry::entry imaged` sorted in an<br>
> alphabetical order, first by name, then version etc.<br>
><br>
> `registry::entry imaged` might be returning in a random order but sorting it<br>
> (with ports coming before their dependencies) doesn't change the result at<br>
> all.<br>
><br>
<br>
</span>[1] and [2] might be useful. The list of ports are passed to<br>
_mportexec after topologically sorting them for installing. This might<br>
also answer some of your previous queries regarding using [mportexec<br>
$workername $install_target] and sorting the dependencies at once.<br></blockquote><div><br></div><div>Thanks for this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Variants is still pending. You could try to integrate sorting and<br>
installation of ports with libsolv and extend variant handling from<br>
your script. You might have to tweak the libsolv code if you pass the<br>
variants like foo+bar-baz. One idea could be to add 'bar' as<br>
dependency and 'baz' as conflict explicitly since it will only read<br>
the portindex for 'foo'.<br></blockquote><div><br></div><div>When you say variants is still pending, do you mean we can't specify particular set of variants along with a port to be installed? So, it always assumes the default variants for a port at present?</div><div><br></div><div>If the variants are still not supported by libsolv, what I think is best to go with calculating dependencies recursively as I'm doing now and then integrate it with libsolv.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Libsolv proved to be faster than our traditional recursive dependency<br>
calculation engine even after reading through the complete portindex<br>
every time it was called.<br></blockquote><div><br></div><div>I had doubts about "reading the portindex contents first and writing into libsolv formatted solvables"  every time when I went through the code but for now, I can take your word.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Let me know if you have any doubts regarding the libsolv code. The<br>
comments should be explanatory enough by itself but feel free if you<br>
want to understand what is actually happening behind the scenes by<br>
libsolv.<br></blockquote><div><br></div><div>The comments are really descriptive there. macports-base can hopefully learn from it.</div><div><br></div><div>- Umesh</div></div></div></div>