Skip to content

(maint) Allow for multiple augeas versions #7

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 7, 2018

Conversation

caseywilliams
Copy link
Contributor

Branches of puppet-agent now variously use three different versions of augeas - 1.4.0, 1.8.1, and 1.10.1. This PR adds support for all three versions (pdk uses version 1.8.1, which is currently the only version of augeas available in puppet-runtime).

Augeas presents a bit of a problem in terms of how to handle multiple possible versions; ruby-augeas depends on having some version of augeas, but it doesn't matter which one. Attempting to successfully include a build_requires 'augeas' line in the ruby-augeas component thus becomes tricky when there are multiple possible augeas versions. If we added separate, version-specific augeas components (e.g. augeas-1.4.0.rb), it seems like we'd need to either:

  • carry some information about the augeas version into the ruby-augeas component in order to set up the requires relationship correctly, or
  • just carefully include the augeas component before ruby-augeas in all cases, hope that no one changes the order, and leave out the build_requires in ruby-augeas.

Neither of these sound great. I decided to do this:

  • Added an :augeas_version setting in the projects that need augeas (i.e. all of them)
  • Kept a single augeas.rb component, which looks to the :augeas_version setting for a version if available; If none is supplied, it uses 1.8.1 by default. ruby-augeas can continue to build_requires this without having to care about the version.

Here are a few example builds for 1.10.x, 5.3.x, and master.

If this seems okay, I may refactor a few other components along these lines (e.g. ruby-stomp) to reduce the number of version-specific component-x.y.z.rb components (and so that people only have to figure out one approach to version selection while they're trying to work on puppet-runtime). If there's some other, cleaner way to accomplish this with vanagon or a different approach someone can think of, that would also be great to hear about.


if platform.is_sles? && platform.os_version == '10'
pkg.apply_patch 'resources/patches/augeas/augeas-1.2.0-fix-services-sles10.patch'
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SLES 10 is no longer supported in puppet-agent, and pdk doesn't need it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you move this into a separate commit?

SLES 10 is no longer a supported puppet-agent platform, and pdk doesn't
support it either.
Allows for a choice between augeas 1.4.0, 1.8.1, or 1.10.1 based on an
:augeas_version project setting. 1.8.1 is kept as the default. Ports
several patches over from puppet-agent for versions 1.4.0 and 1.10.1.
@ScottGarman
Copy link
Contributor

Seems reasonable. 👍

Copy link
Contributor

@underscorgan underscorgan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this ready for merge?

@caseywilliams
Copy link
Contributor Author

@underscorgan yep, ready for merge

@underscorgan underscorgan merged commit f0cbc34 into puppetlabs:master Mar 7, 2018
@caseywilliams caseywilliams deleted the augeas-update branch July 10, 2018 19:39
witjoh pushed a commit to witjoh/puppet-runtime that referenced this pull request Feb 24, 2021
(SDK-213) Add custom rbconfig stuff from puppet-agent for Windows.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants