Hi On Sun, Aug 6, 2017 at 6:43 PM, Jackson Isaac <ijack...@macports.org> wrote:
> Hi, > > On Sun, Aug 6, 2017 at 5:41 PM, Umesh Singla <umeshksin...@macports.org> > wrote: > > On Sat, Jul 22, 2017 at 7:26 AM, Joshua Root <j...@macports.org> wrote: > >> > >> > >>> For now, I'd like to ask in what order does "registry::entry imaged" > >>> returns the port list? Because I'm running the sorting function which > the > >>> restore_ports.tcl uses but it's giving me the ports in the same order > as > >>> result. > >> > >> > >> Probably just ordered by rowid, i.e. might as well be random. Note that > >> the sort_ports proc from restore_ports.tcl does not take a list of > registry > >> references like registry::entry returns, but a list of strings > representing > >> port names, versions and variants in the format generated by 'port > >> installed'. > > > > > > `port installed` returns the result of `registry::entry imaged` sorted > in an > > alphabetical order, first by name, then version etc. > > > > `registry::entry imaged` might be returning in a random order but > sorting it > > (with ports coming before their dependencies) doesn't change the result > at > > all. > > > > [1] and [2] might be useful. The list of ports are passed to > _mportexec after topologically sorting them for installing. This might > also answer some of your previous queries regarding using [mportexec > $workername $install_target] and sorting the dependencies at once. > Thanks for this. > Variants is still pending. You could try to integrate sorting and > installation of ports with libsolv and extend variant handling from > your script. You might have to tweak the libsolv code if you pass the > variants like foo+bar-baz. One idea could be to add 'bar' as > dependency and 'baz' as conflict explicitly since it will only read > the portindex for 'foo'. > 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? 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. > Libsolv proved to be faster than our traditional recursive dependency > calculation engine even after reading through the complete portindex > every time it was called. > 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. > Let me know if you have any doubts regarding the libsolv code. The > comments should be explanatory enough by itself but feel free if you > want to understand what is actually happening behind the scenes by > libsolv. > The comments are really descriptive there. macports-base can hopefully learn from it. - Umesh
