GSoC'17: Add migrate action to port command Project

[Clemens Lang]

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.


HTH,
-- 
Clemens