Hi On Sun, Aug 6, 2017 at 6:56 PM, Joshua Root <[email protected]> wrote:
> On 2017-8-6 22:11 , Umesh Singla wrote: > >> On Sat, Jul 22, 2017 at 7:26 AM, Joshua Root <[email protected] <mailto: >> [email protected]>> 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. >> > > Yes. The order of the input lines doesn't matter for restore_ports.tcl of > course because it's sorting them. My point was just that that particular > sort procedure takes something like "zlib @1.2.11_0 (active)" as input, > rather than "::registry::entry150". Yes, I was aware of that anyway. > > `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. >> > > This could easily be true in some cases but definitely not in the general > case. Are you testing on real-world registry contents or just on an > installation you created recently for testing? In the latter case, each > port will happen to come before its dependents simply because dependencies > are installed first. After some upgrading of ports over time, in > practically random order, this will often no longer be the case. > I was only trying on installation I created which had about 60 ports in total but only 5 requested. So, you are right because the order was always stored sorted and was never modified. Thanks. > > Attached is a small script that I used to demonstrate that this property > does not hold in my own registry. There, entry0 is fftw-3, and comes before > its dependent entry243 (py27-numpy). On the other hand, entry267 is > py27-setuptools, which comes after its dependent entry76 (py27-nose). > - Umesh
