[GSoC] migration

Umesh Singla umeshksingla at macports.org
Wed Jul 19 22:43:18 UTC 2017


Hi Brad,

With another week over, I have the following updates to share.


*GSoC Week #7 (13 Jul - 19 Jul)*

I moved the things to migrate action instead of 'restore' since 'restore'
looks a subset of 'migrate', so can be dealt easily once migrate is over.


Agenda for last week:

The migrate action consisted of three parts, creating a new snapshot,
uninstall installed ports, re-installing them for the last snapshot.

1. Creating a new snapshot was over before, though some refactoring is
still left.

2. Regarding uninstalling installed ports, I took the help of reclaim.tcl
which works with the migrate action now. It uses
sort_portlist_by_dependendents procedure. So, all in all, it uses
"registry_uninstall::uninstall".

3. Re-installing the ports from the portlist. I took the help of
restore_ports.tcl here, which works when called migrate. It uses sort_ports
[1] function.


When we install, is it fine to use [mportexec $workername $install_target]
from migrate.tcl?

What took time is that these two functions at present take the port list in
different formats. So, I tried debugging by simply printing on console
method to know the formats of the two.

I want to use the sorting function for dependencies only once instead of
calling it twice while uninstalling and then re-installing. I'm still
working on it and actually, close to solve this but thought, better send
the weekly update first.


For the next one week:

   1. make appropriate changes to procedures according to one format.
   2. write for “SELECT PORTS FROM SNAPSHOT ..”, i.e. connect it with the
   new tables we have.
   3. try finishing the migrate action asap?


Points:

Since migrate action creates a snapshot within and then uses it to redo the
whole state, I feel creating a snapshot here explicitly is redundant.

Internally snapshot also uses the same registry C functions to get the
information first and then save to database as [registry::entry imaged]
does, so instead of first retrieving from [registry::entry imaged], saving
it in sqlite and then again fetching all the info using the snapshot-id we
just got, can't we directly use [registry::entry imaged] here? Am I missing
something?

Regarding "selected" snapshot for 'restore', it looks fine.


New points which I made during pondering to save for the end:

   1. Add ui_debug statements
   2. Catch some error-prone areas.
   3. Remove the useless/structure comments and add actual doc-strings.
   4. Add copyright notices
   5. Using ui_msg instead of puts and else. Should probably add that.


Also, here's my view of restore_ports.tcl of what it does:

   - macports prefix configs
   - umask 022
   - set portList [read_portlist $filename] - reads the portlist from file
   supplied or stdin
   - set operationList [sort_ports $portList]
      - sort_ports $portList
         - extracts name, version, variants, active for a port
         - sets it 1 in port_in_list if not there, else increments the
         count for that port
         - if port dependencies for the combination (port_name, its
         variants) doesn’t exist already, fetches them using
         dependenciesForPort(port_name, its variants), kind of recursively.
      - dependenciesForPort $port_name $variants
   - install_ports $operationList
      - checks $active for a port and use it to decide install_target
      - uses mportexec for installing


Please find the work log here [2]. It is largely in work-in-progress state.


[1]:
https://github.com/macports/macports-contrib/blob/master/restore_ports/restore_ports.tcl#L52

[2]: https://github.com/macports/macports-base/commits/gsoc17-migrate


Best Regards,

Umesh Singla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20170720/db66d52b/attachment.html>


More information about the macports-dev mailing list