Issue #2157 has been updated by Ken Barber.
Yury Zaytsev wrote: > Ken Barber wrote: > > but I'm sure Redhat/Fedora repackagers may feel they want to modify it to > > /usr/libexec to suit their 'standards'. *sigh*. > > You bet! > > -- RH Packager Thats funny :-). So Redhats official position is: http://fedoraproject.org/wiki/Packaging:Guidelines#Libexecdir Which is a 'may' not a 'must'. On BSD - it looks like 'libexec' is the correct place on the other-hand ... as libexec seems to have spawned from BSD. A lot of GNU tools also used libexec (like emacs) so I think this is how it found its way onto linux as well. I'm thinking we should take the high road and use the FHS for Linux: /usr/lib/facter To keep documentation consistent. There is an argument for using: /usr/libexec/facter For BSD based OS though ... what do people think? I think BSD people (and OS X) would expect libexec to be used. But keeping it consistent for Linux would be nice - at least it would make documentation a little clearer. As it stands I'll need a table to point this stuff out :-). In a way its a shame libexec is not in the FHS - but alas that is a different discussion. I'm still trying to find out what Solaris uses ... all these years and I'm still unable to find a published standard for how they lay things out. If anyone has anything let me know. I presume its going to be /usr/libexec as well. Also ... beyond the basic "libexec" path ... I wanted to use the following as the full path for external facts: $FACTER_LIBEXEC/ext ... but I'm totally open to suggestions. 'ext' is brief but probably not that obvious. I plan on dropping a README file in their at least to explain what the directory is for in case people stumble upon it. ---------------------------------------- Feature #2157: External fact support in /etc/facter.d https://projects.puppetlabs.com/issues/2157 Author: Paul Nasrat Status: Code Insufficient Priority: Normal Assignee: Ken Barber Category: Target version: 1.7.0 Keywords: Branch: kbarber/tickets/master/2157-external_fact_support Affected Facter version: Facter should support non-ruby facts, preferably in /etc/facter.d. It should support these facts being either executable, in which case the result is the value of the named fact, or in a data format such as yaml, in which case the data file is read in and interpreted as the fact value. It probably makes sense to initially stick to yaml for data formats, since json doesn't ship with ruby, and to also allow executable facts to return either a plain string or yaml. Note that we can do this without supporting any kind of overriding, but it'd be much better if we supported multiple (configurable?) fact directories, with a search path. Thus, if Facter shipped with /etc/facter.d/myfactname and you wanted to override it, you could do so by creating a new file and putting it in a higher-priority location rather than editing a file distributed with the core. Given we're adding structured data support, namespaced facts would be supported with directory structures; e.g., /etc/facter.d/my/fact/name would resolve to my::fact::name. Ideally, the long-term direction here would be not to require any pure-ruby facts, such that the Facter library could be rewritten in any other language and it would function the same, because all of its actual data is outside of ruby. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
