Re: Structuring configuration file versioning support in pkgsrc

[Keivan Motavalli <keivan%motavalli.me@localhost>]

if no support for pulling configuration targeting the machine role is needed during package installation or upgrade phases (anyone else has feedback?), then it makes sense to keep the whole remote functionality out of packages and pkgsrc, delegating it, backups, interactive merging to a separate tool which I planned to write anyway. This way I would avoid having to write duplicate code in pkginstall/pkgtasks and the tool.

as for targeting jlam's framework, it was suggested when writing the proposal, but decided against as activity seems stalled there. 
Looking at the code of both pkgtasks and pkginstall scripts, it looks like a good idea to base the work on the new framework, but I think I'd then need some guidance in integrating code back into pkginstall

> On May 22, 2018 at 12:45 PM Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
> 
> 
> On Tue, May 22, 2018 at 11:05:46AM +0200, Keivan Motavalli wrote:
> > Yes, atomicity could become an issue later on, but if goals are to
> > change so broadly that support for remote configuration
> > repositories shouldn't be implemented (yet?), anything can be
> > rethought.
> 
> One other aspect I wanted to raise is whether this project should target
> mk/pkginstall or pkgtools/pkgtasks. I'm not sure what the status of
> jlam's rework it, but it would certainly be the long term goal. It might
> even be easier to work on for prototyping in your case and it shouldn't
> be too hard to merge the changes back into mk/pkginstall. This is just
> food for thoughts.
> 
> Joerg