From: Greg Swift <xaeth(a)fedoraproject.org>
To: Development discussions related to Fedora
<devel(a)lists.fedoraproject.org>
Date: 10/23/2012 15:51
Subject: Re: Fixing Puppet in Fedora/EPEL
Sent by: devel-bounces(a)lists.fedoraproject.org
On Tue, Oct 23, 2012 at 1:46 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
> On Tue, Oct 23, 2012 at 11:30:49AM -0700, Michael Stahnke wrote:
>> I am still not in favor of a puppet3 package. This is largely due to
>> overall compatibility. Puppet is a distributed system. Having the
>> package be called puppet in some repositories and puppet3 in others
>> (along with bin files/utils) will only the make the overall
>> user-experience of Puppet worse IMHO.
>>
>> Also if the existing Puppet (2.6.x) stays out there, how would a user
>> know that 2.6 is no longer maintained? Does having a second package
>> without an upgrade path leaves the end-user out-to-dry in the
longrun?
>
> We can make the new package available, and do something to publicize
that
> there is going to be a change. When 2.6.x is no longer
maintained for
> security updates, the new package gets the old name and obsoletes the
> temporary name.
>
> If there's some way to put deprecation notices into the default output
for
> puppet, it might be worth considering that.
An easy way would be to roll and update to the 2.6 release that logs a
deprecation error on start via the init script.
And ideally the message would also land in the tagmail deliveries once
upon first catalog compilation after the puppet master is restarted --
much like the 2.7 deprecation notice for dynamically scoped variables was
handled. That was a very nice compromise between (1) you should see this
and (2) not being annoying about it. I would personally like to see the
puppet folks adopt something like this as an ongoing policy for all
deprecations/obsoletions with as much as advance notice as reasonably
possible.
--
John Florian