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. HTH, -- Clemens
