Created attachment 179624 [details] Patch for 4.9.1 update and specify new localdir Puppet 4.9.1 has been released. Here we update the version, add a patch for lib/puppet.rb, and add an option to the call for install.rb. The extra changes here are to support loading locales, which is new in 4.9.0. I believe /var/puppet/share/locales is the correct place for this change.
Hello, I was about to submit a patch to update to 4.9.4 and found this PR. Regarding installing the locales, I guess a better place would be in the usual locales directory (${PREFIX}/share/locale) or if it uses some special i18n features, maybe in the $RUBY_SITELIBDIR/puppet/locale directory; but trying to figure out what would be the best, I saw that the port only creates an empty directory… There seems to be no locales in the tarball. Do you have any hint?
Created attachment 181080 [details] Svn diff of sysutils/puppet4 for version bump. I've updated the patch to do as you suggest and use PREFIX/share/locale, thank you. It seems the installer creates the directory if it doesn't exist, but I've set the permissions in the plist to match what the system users. If there is better way to avoid including this directory in the plist at all, please let me know.
Sorry, I was not clear about what I wanted to say. Let me retry :-) Beside the update of the port itself, I understand the changes are related to internationalization (i18n) stuff. However, it only ensures a directory exist, and does not install any i18n file. So I am wondering « how is this useful? » and « do we need to introduce this in the FreeBSD ports tree » ? When a port installs i18n things, that usually creates a tree of files under the « locale » directory. For example if you take a look at deskutils/tomboy's pkg-plist, you will see one file per language: ----------------- 8< ----------------- share/locale/af/LC_MESSAGES/tomboy.mo share/locale/ar/LC_MESSAGES/tomboy.mo share/locale/as/LC_MESSAGES/tomboy.mo share/locale/ast/LC_MESSAGES/tomboy.mo share/locale/be/LC_MESSAGES/tomboy.mo share/locale/be@latin/LC_MESSAGES/tomboy.mo share/locale/bg/LC_MESSAGES/tomboy.mo share/locale/bn/LC_MESSAGES/tomboy.mo [...] share/locale/uk/LC_MESSAGES/tomboy.mo share/locale/vi/LC_MESSAGES/tomboy.mo share/locale/zh_CN/LC_MESSAGES/tomboy.mo share/locale/zh_HK/LC_MESSAGES/tomboy.mo share/locale/zh_TW/LC_MESSAGES/tomboy.mo ----------------- 8< ----------------- Since I don't see such files, this seems no-op to me. However, maybe I am missing something, that's why I was asking for more details if you have some, or wondering if we can't just ignore this for the moment if it is non-usable. Thanks!
I agree that including a new directory without a reason is not great. I'll take advice on the rest. I'm a little confused about the locales at this point, and as you mention its not stabilized with docs etc. We're not currently patching the install.rb, which I think we'd need to to in order to avoid the mkdir. Simple enough, but I'd thought that fewer patches are preferred. I checked the tar of 4.9.4 and the locales are still not included. It looks like its included with the unreleased 4.10.x. Perhaps we rmdir post install?
No problem for leaving alone the locale related part for now. However, do you have an objection to updating to 4.9.4?
Created attachment 181124 [details] Update to 4.9.4
Updating to 4.9.4 sounds good. I've not been able to test it on a master due to a some hiera changes, but the agent has been good.
Hello, As you are the maintainer, I do not want to force you to update to the latest release if you are not ready for this yet. There are fixes related to hiera in each release since 4.9.1, so maybe it's not stable enough at the present time for advanced usage (I only use basic features of Hiera ATM). I can update the port to 4.9.1 for now, and update it again when you think we are ready to ship a newer version. I may also try to help you with your problem if you can share the details of it? Tell me what you think!
Hi Romain, The bit about 4.9.4 that I'm uncertain about, is that it looks like hiera users who are using the 'eyaml' backend will require require action for their setup to continue work as expected. I think this has the information. https://docs.puppet.com/puppet/4.9/hiera_migrate.html#updated-hiera-eyaml-users-go-for-it The release notes seem to indicate that for the common case, there is no action required. I suspect that this is stable enough, I was only nervous of surprising users without a helpful message. Perhaps "go read the release notes" is enough? I'm unsure. Also, thank you for helping here. I'm never sure who to ask to review the Puppet PRs, and sometimes they sit out for a while without review. So I appreciate your time.
As I understand the release node, there is no change for users of eyaml: they already have installed hiera-eyaml by some mean, so updating should not be a surprise. By the way, I can't find hiera-eyaml in the ports. So I guess that if someone is using Puppet + hiera-eyaml, he will be able to figure out what happens if something strange happens.
Ah, that's a great point. Folks using hiera-eyaml are already on their own. You've convinced me. 4.9.4 sounds great!
A commit references this bug: Author: romain Date: Thu Mar 30 19:07:58 UTC 2017 New revision: 437323 URL: https://svnweb.freebsd.org/changeset/ports/437323 Log: Update to 4.9.4 PR: 216807 Submitted by: Zach Leslie <freebsd@zleslie.info> (Maintainer) Changes: head/sysutils/puppet4/Makefile head/sysutils/puppet4/distinfo
Excellent, thank you!