tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [GSOC 2018] project proposal: Version control config files
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.
Home |
Main Index |
Thread Index |
Old Index