Puppet 4

[Michael Stahnke]

On Fri, Jun 5, 2015 at 8:15 AM, Michael Stahnke <stahnma at puppetlabs.com>
wrote:

>
>
> On Fri, Jun 5, 2015 at 6:31 AM, John Florian <john.florian at dart.biz>
> wrote:
>
>> On Fri, 2015-06-05 at 01:12 -0400, Nico Kadel-Garcia wrote:
>> > On Thu, Jun 4, 2015 at 2:21 PM, John Florian <john.florian at dart.biz>
>> wrote:
>> > > I’ve been curious how Fedora plans to tackle inclusion of Puppet 4,
>> but
>> > > haven’t heard even a peep on the subject.  As described[1], they’ve
>> moved to
>> > > an all-in-one packaging process that “includes Puppet 4, both Facter
>> 2.4 and
>> > > CFacter 0.4, the latest Hiera and Mcollective, as well Ruby 2.1.5,
>> OpenSSL
>> > > 1.0.0r, and our gem dependencies.”  Furthermore, “the package
>> installs into
>> > > its own area in /opt/puppetlabs”.  Thus upstream is both bundling and
>> using
>> > > very Fedora-unfriendly file locations.  L
>> >
>> > As long as it's in "/opt", what's the problem? That's what /opt is
>> > for! Unwielding and resolving individual components of an integrated
>> > tool suite is often a nightmare, which is why puppet, chef, and
>> > numerous commercial packages do the same thing.
>>
>> Packaging Guidelines for one.  My personal belief is that /opt should
>> only be populated by the local admin, never the distro nor a vendor.
>> Personally I do so using a scheme like /opt/$VENDOR/$PRODUCT/$RELEASE,
>> but to my knowledge the FHS has never ratified anything like that.  The
>> FHS seems to take a rather vague stance on /opt overall IMHO.
>>
>
Could functionally explain the difference then between /usr/local and /opt?
Opt has been for thrid-party/commercial/optional software for as long as
I've used *NIX.  /usr/local more for the local admin to build/compile/setup
what he/she would like.



>
>> Just as a point of record, we do /opt/$VENDOR/$PRODUCT
>
> not so much with the release, but we're close to what you wanted.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150605/0c1e6007/attachment.html>