Please revert Puppet 5 dropping patch

[thomasgoirand]

Hi,

In this commit:
97dd16f

you are dropping puppet 5 support. Unfortunately, in Debian, we were not able to package Puppet 6, due to some problems packaging jruby. So Bullseye will continue to contain Puppet 5. Therefore, I would like to kindly ask you to continue to support us for at least the following 2 to 3 years.

Cheers,

Thomas Goirand (zigo)

[bastelfreak]

Hi,
[disclaimer: I'm not a maintainer here]
Puppet 5 is end of life since a few months. It won't receive any security patches. Why should this module keep supporting it? That just encourages users to use EOL software. Debian could have packaged the agent without the server. Also Puppet provides packages for Debian and users are not forced to update this module. So why should modules keep supporting this old Debian version?

[ekohl]

Disclaimer: not a maintainer either.

I do use the Puppet packages from Debian and am highly disappointed that they chose to keep Puppet 5. IMHO the puppet-master package should have been dropped instead. Anyone who needs a Puppet server would be forced to run it with the official packages, containers or otherwise but at least the ecosystem would not have been held back.

IMHO requiring the ecosystem to support an EOL version for 2 to 3 years is unreasonable and puts a huge burden on admins who do run Puppet with the Debian packages.

I am currently considering my options:

• Move to official packages
• Pull puppet-agent from experimental
• Rebuild experimental packages for stable in my own repo
• Drop Puppet altogether

Right now the third option feels like the most reasonable.

[trevor-vaughan]

@ekohl What's the case against the official packages? I personally dislike the AIO bundle but it certainly works.

[ekohl]

@trevor-vaughan as you say, the AIO bundle.

[thomasgoirand]

Hi.
Well, we didn't "choose" puppet 5, we did as much work as possible, but unfortunately we missed the deadline for the Bullseye freeze.
About the security fixes, you can be sure that we WILL do the necessary work if we see this happens. This has always been the way it works.

As for the upstream packages from Puppetlabs, I've been very disappointed by them when doing the packaging for Debian. Not only they do embed so many components, which is a very bad practice, but the Puppet 6 dependency chain is kind of crazy. They use modules in the Clojure ecosystem which are completely deprecated, and some of them for more than 5 years (like for example cljx). Embedding their own ruby, clojure and so on isn't a good idea either. So, yeah, you can advise someone to use the upstream packaging of Puppet 6, but beware that it's not as clean as one may think. I myself wouldn't use them. Evaluating the quality of some package unfortunately goes beyond just "oh, it works..." !!!

As for Bullseye, the current plan is to finish the work for packaging Jruby, then go on with packaging Puppet 6 in Sid/Testing, and then provide an official Bullseye backport for it.

No, we will not drop puppet at all from Debian. This really is not on the table. Maybe we could convince the Debian Stable release team to accept the remaining few components later on to get Puppet 6 in Bullseye, but I'm really not sure of that (they generally do not agree with such plan).

Anyways, my original post was to ask to continue to support Puppet 5 for a bit more. That would be nice also for anyone still continuing to work with Debian Buster, which will not get any update of Puppet.

Your thoughts?

[trevor-vaughan]

@thomasgoirand Fundamentally, the AIO approach is simply a 'pre-container' construct. The same dependency issues and everything else apply. Any "statically compiled" blob has this issue whether it's a container, Go or Rust binary, or massive C blob.

Since the world is trending this way, I'm basically just living with it until the next zlib meltdown.

[ekohl]

Well, we didn't "choose" puppet 5, we did as much work as possible, but unfortunately we missed the deadline for the Bullseye freeze.

I understand this wasn't an explicit choice but rather implicit. I also understand that it's not easy but rather hard. I'm mostly unhappy with the end result of everything, as I'm you are as well.

As for the upstream packages from Puppetlabs, I've been very disappointed by them when doing the packaging for Debian. Not only they do embed so many components, which is a very bad practice, but the Puppet 6 dependency chain is kind of crazy. They use modules in the Clojure ecosystem which are completely deprecated, and some of them for more than 5 years (like for example cljx). Embedding their own ruby, clojure and so on isn't a good idea either. So, yeah, you can advise someone to use the upstream packaging of Puppet 6, but beware that it's not as clean as one may think. I myself wouldn't use them. Evaluating the quality of some package unfortunately goes beyond just "oh, it works..." !!!

No argument there. While I haven't looked at their deb packages, I have plenty of complains about their RPMs. Hence why I generally prefer the distro native packages.

No, we will not drop puppet at all from Debian. This really is not on the table. Maybe we could convince the Debian Stable release team to accept the remaining few components later on to get Puppet 6 in Bullseye, but I'm really not sure of that (they generally do not agree with such plan).

I was suggesting to only drop the server packages. If there is a puppetserver packaged for Bullseye, it can be delivered via backports or an alternative packaging.

[thomasgoirand]

@trevor-vaughan It's fine if you're happy with the huge blobs, though in Debian, we still don't do that, and I'm happy we don't. BTW, even for Go, we do build from source.

@ekohl I prefer to keep at least a version of Puppet (the server) in Debian, even if that's Puppet 5. It's not the first time (and certainly not the last time) that we go without upstream support for something. That being said, we can hopefully still get Puppet 6 Server done at some point in time, during the life of Bullseye. Since we got nearly all the dependencies done (all but Jruby), it should be rather easy to backport. See the packaging status here:

https://wiki.debian.org/Teams/Puppet/Work

My original post wasn't to give an update on the Puppet 6 packaging in Debian, even though I'm happy to provide information, this bug tracker is probably not the best place. :)
Anyways, can we go back on topic ? :)

So, I'm once more asking: could we get Puppet 5 support for a little longer for this package? FYI, I've just uploaded it to Debian. Yes, I'm also packaging puppet modules that I find interesting and that I use myself. All that in order to deploy OpenStack in a self-contained environment (ie: only the Debian archive, not a signle external artifacts needed). FYI, I'm planning to use camptocamp-systemd in this software: https://salsa.debian.org/openstack-team/debian/openstack-cluster-installer

If you're telling you still don't want to continue supporting Puppet 5 for a little longer, I'd understand the decision and wouldn't take it bad, but as well, I'll probably reconsider using camptocamp-systemd, which would be a shame considering how nice your module is.

Thanks for writing and sharing this puppet module,
Cheers,

Thomas Goirand

[raphink]

Hi there 👋

Official maintainer here.

As an Ubuntu developer for the last 15 years or so, I really dislike the AIO/omnibus approach as well. In fact, this led us at Camptocamp to move to containers when we switched our Puppet infra to Puppet 4.

That said:

• there's at least one good reason for AIO packages: official/paid support from @puppetlabs is made much easier by freezing all dependencies
• our modules (including puppet-systemd) depend on base modules (such as stdlib) that have dropped support for Puppet 5.

So yes, I'd rather drop support for Puppet 5 in our modules than to have to support the whole stack on our own. I know how this feels for distro packagers (for having been on your side) & I'm sorry for that. We don't use Puppet 5 anymore, and none of our clients is paying us to support it in our new module releases.

[kenyon]

@thomasgoirand you can always pin to the last release that does support Puppet 5.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.