Re: [GSOC 2018] project proposal: Version control config files

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

I have further refined how selecting the appropriate branch before pulling 
should work, does it make sense for pkgsrc?

[...] additional features could be implemented, such as support for pulling 
site and <package,version,range,role> specific configuration from a networked 
repository upon installation [...]

All CONF_FILES needed should be hierarchically placed in accordance with 
pkgsrc software categories and package naming (eg, under /mail/postfix/) and 
branched with a name expression of the system role (eg, myproject-
testing_net02) and version information (eg 3.2.5_3.0_any), so that the file at

mail/postfix/main.cf branched as 3.2.5_3.0_any_myproject-testing_net02,

with meanings exactVersion_rangeStart_rangeEnd_role_optionalHostname

would be up for checks disposed this way:

first, all branches whose range is compatible with the version of the package 
being installed are selected.

Then, if a role other than "any" is specified by the branch name, it is 
compared with the role defined in pkgsrc configuration and selected. The last 
part of the branch name is optional and, if present, compared character by 
character with the system hostname, finally selecting the branch that best 
matches it.

The checks now further refine the candidates: if a branch exactly corresponds 
with the version of the package being installed, that branch gets selected, 
otherwise the procedure should choose the next closest one.

The file is then copied on the system. Each branch should contain all the 
configuration files the package needs, so that versions don't get mixed up.

On Friday, March 23, 2018 6:29:02 PM CET Keivan Motavalli wrote:
> Thanks.
> I have updated the document at https://www.scribd.com/document/374557117/
> GSOC-2018-public-proposal-conf-versioning-in-pkgsrc?
> secret_password=eEZwOcGIyoie156VXgko
> fixing some language and adding a convention for specifying a package
> version range  the branch is compatible with, how the repo should be
> structured and how to select the closest matching branch for the files.
> 
> Hoping it all goes well, I copy down here how I'm thinking to do it, for
> feedback:
> 
> [...] additional features could be implemented, such as support for pulling
> site and <package,version,range,role> specific configuration from a
> networked repository upon installation [...]
> 
> All CONF_FILES needed should be hierarchically placed in accordance with
> pkgsrc software categories and package naming (eg, under /mail/postfix/) and
> branched with a name expression of the system role (eg, myproject-
> testing_net02) and version information (eg 3.2.5_3.0_any), up for checks
> disposed this way:
> 
> If a branch exactly matches the version of the package being installed, that
> branch gets selected, otherwise the procedure should choose the next
> closest one and check if the version of the package being installed is
> included in the range information conveyed by the naming convention.
> 
> Then, if a role other than "any" is specified by the branch name, it is
> compared with the role defined in pkgsrc configuration and selected. The
> last part of the branch name is optional and, if present, compared
> character by character with the system hostname, finally selecting the
> branch that best matches it.
> 
> Fields are separated by "_"
> 
> On Friday, March 23, 2018 1:50:34 PM CET you wrote:
> > Cool, looks very serious and you did research :-)
> > Hopefully it goes well, although it depends on external factors like how
> > many slots we have.