[Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020

[Thomas Goirand]

On 3/29/22 21:21, Antoine Beaupré wrote:
> On 2022-03-29 21:14:42, Thomas Goirand wrote:
>> On 3/29/22 20:58, Antoine Beaupré wrote:
>>> On 2020-05-16 21:13:25, Martin Konrad wrote:
>>>> Hi,
>>>>> The others are related to other operating systems than Debian, so I
>>>>> really wonder if we need them (yum, really? zfs and zone are for
>>>>> Solaris, and scheduled_task is for windows...).
>>>> If we want to make transitioning from Puppet 5 to Puppet 6 as easy as
>>>> possible I think there is no way around packaging _all_ modules that
>>>> were bundled with Puppet 5. Keep in mind that some users might run their
>>>> Puppet master on Debian while having agents running on different
>>>> operating systems that might use yum, zfs etc.
>>>
>>> Given how late we are to this party (Puppet 5 has been EOL over a year
>>> now, and Puppet 6 is still not in testing), I don't think that should be
>>> a blocker.
>>>
>>> It's kind of expected that major upgrades in Debian somewhat throw a
>>> wrench in your manifests and you need to run around like a chicken with
>>> your head cut off to plug all those leaks. That's an upstream issue, and
>>> not one we should try to fix ourselves.
>>>
>>> IMHO.
>>>
>>> The focus here should be to provide a working Puppet 6 agent, and not
>>> fight with the server-side stuff, which, BTW, is in an even worse shape
>>> because the puppetserver code is not packaged *at all* in Debian
>>> still. See:
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830904
>>> https://veronneau.org/puppetserver-6-a-debian-packaging-post-mortem.html
>>>
>>> Having Puppet agent 6 in Debian would at least allow us to migrate
>>> fleets to an eventually Puppetserver 7 package in Debian bookworm, or at
>>> least use the upstream Puppetserver 6/7 packages.
>>>
>>> A.
>>
>> Hi,
>>
>> I don't agree with this view.
> 
> Sorry, could you clarify which part you disagree with?

I believe that our users would be served better if we can finish the 
server side of things before uploading a new client with a different 
version than the server.

We've seen how things are done upstream: it's ugly. Pushing our users to 
move to the upstream packages is a disservice.

Maybe we can run a sprint during the coming debcamp so we can work on 
Jruby and fix everything?

Cheers,

Thomas Goirand (zigo)