GSoC'17: Add migrate action to port command Project

[Bradley Giesbrecht]

> On Mar 30, 2017, at 12:13 PM, Clemens Lang <cal at macports.org> wrote:
> 
> Hey everybody,
> 
> On Tue, Mar 28, 2017 at 01:37:55PM -0700, Bradley Giesbrecht wrote:
>>> On Mar 28, 2017, at 11:55 AM, Umesh Singla <umeshksingla at gmail.com> wrote:
>> 
>> Does the migrate and snapshot actions help you divide the 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.
>> 
>> It is early on but I can imagine a schema like:
>> 
>> Tables
>> snapshots (
>> 	id,
>> 	datetime,
>> 	note
>> )
>> snapshot_ports (
>> 	id,
>> 	snapshots_id,
>> 	port_name,
>> 	requested
>> )
>> snapshot_port_variants (
>> 	id,
>> 	snapshot_ports_id,
>> 	variant_sign, // (we allow plus and minus variants like +variant1 -variant2)
>> 	variant_name
>> )
> 
> This follows all the good rules of data normalization, but MacPorts
> internally uses a different representation of variants. Not saying I
> prefer that, just saying that we already have code to deal with it.
> 
> I would also not mind changing the format. It's a detail we can ignore
> until the project starts, though.
> 
> I've also left this as a comment in the proposal.
> 
> 
>>> 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?
> 
> I would suggest that the first action of a 'port snapshot'/'port
> migration' action would be to recompile base, i.e. the equivalent of
> 'port -f selfupdate'. This would allow us to implement this completely
> in Tcl/C and use the existing abstractions and helper functions that
> MacPorts already has.
> 
>>> Also, will the project phasing out dependency on XCode tools affect
>>> this one anytime soon?
> 
> I won't, but thanks for keeping it in mind.
> 
> I've also left some other comments in your proposal. Feel free to take
> a look.
> 
> 
> On Wed, Mar 29, 2017 at 01:38:23PM +0200, Mojca Miklavec wrote:
>> One of the biggest pains at the moment is the fact that we don't
>> record requested variants anywhere. We do record requested ports, but
>> not the variants.
> 
> I agree that's a pain point we should change, but I don't think that
> should be covered by this proposal, unless it turns out to be way too
> small.
> 
> 
>> I would like to see one more scenario covered if there is sufficient
>> time. When users change some setting in their macports configuration
>> (I have https://trac.macports.org/wiki/LibcxxOnOlderSystems in mind,
>> but there might be other cases), it would be super helpful if users
>> with a working MacPorts installation could run
>>    sudo port <something>
>> which would:
>> - remember which packages are installed
>> - deactivate all of them (and perhaps move the files to some temporary
>> location just in case they are needed again)
>> - reinstall the same packages using the new settings
>> 
>> Basically the same scenario as with regular migration, except that the
>> user would not upgrade the OS, only some of the basic macports
>> settings (OK, I'm not sure how exactly you planned to implement the
>> migration tool, I'm just speculating).
> 
> Good idea, that could just be a run of 'port snapshot' and 'port
> migrate' without the base update part.

Or migrate could call a “restore” action:

port snapshot // create a snapshot
port restore // restore a snapshot, default to last snapshot
port migrate // port snapshot, port selfupdate and port restore

And restore can accept a snapshot id:
port restore snapshot=20170330154118


—
Brad