> On Mar 30, 2017, at 12:13 PM, Clemens Lang <c...@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 <umeshksin...@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
