[GSoC] migration

[Umesh Singla]

Hi

On Sun, Aug 6, 2017 at 6:56 PM, Joshua Root <jmr at macports.org> wrote:

> On 2017-8-6 22:11 , Umesh Singla wrote:
>
>> On Sat, Jul 22, 2017 at 7:26 AM, Joshua Root <jmr at macports.org <mailto:
>> jmr at 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.
>>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20170807/1ef3bedb/attachment.html>