Hi
> I believe at a minimum we should plan on two new actions, port “snapshot”
> and “migrate”. A snapshot will the installed ports, their variants and if
> the port was “requested”.
>
> The migrate action will call the snapshot action to create and/or use
> snapshots to rebuild ports on the new platform.
>
This looks quite a plan.
So, what snapshot action will do is to take a "snapshot" of each installed
port and keep a list of these snapshots having a name, requested boolean
and other required info (will try to figure it out soon) additionally.
A variants table will help to specify the appropriate variants, so
basically an indirect version of this: `sudo port install port_name
+variant1 +variant2`.
Migrate action will take these snapshots and use the original guidelines in
the migration docs to rebuild acc to the specifications we now have.
Correct me if I'm wrong.
> I think it is a good idea to include snapshot as an early milestone.
> Does the migrate and snapshot actions help you divide the work?
>
Yes, thanks, this gives a lot of direction to my work.
> The snapshot action is basically an inventory of what is installed along
> with meta data like requested and variants. We will store snapshots in our
> sqlite database.
>
I hope I understood it well as above.
>
> > I don't know if we'll allow Tcl to run in the new environment.
> Otherwise, it seems to implement port with a bash script calling on sqlite3
> on the macports registry/registry.d to get the relevant data.
>
> I think we can require any version of port that includes the migrate
> action, I do not think we will need bash. Clemens, others, do you concur?
>
That time, I was trying to say that for a more general scenario, it'll take
to implement port with a bash front-end that invoked sqlite3 directly upon
the MacPorts registry (located in ${prefix}/var/macports/registry/registry.d)
(not anymore) and extracting the required data. Yes, the above seems an
elegant solution but still migrate action needs more implementation
detailing. Let me work on it.
> Also, will the project phasing out dependency on XCode tools affect this
> one anytime soon?
> Good question, I cannot give you a definitive answer at the moment but we
> should keep this in mind.
>
will include this as stretch goal or something like "Plans after GSoC" :D
An additonal point of thought would be to resolve the conflicts arising if
there are conflicting ports in the list and I guess, order of reinstalling
ports could also be one such factor for conflict if not the default
variants?
Thanks,
Umesh
