And FYI, not everyone has a need to stay on a supported distro. We don't all run public-facing web services. A system on a secure LAN could run for the next 200 years and it wouldn't matter that Canonical or PHP stopped releasing security updates.
Unless there's a size limit to his Launchpad repos I'm not aware of, he simply has no excuse other than being an arrogant authoritarian.
I can sympathise the maintainer thoughts but only up to a certain degree. In a perfect world we would all be able to plan and upgrade accordingly on time and without any hiccups but this is not always the case.
We've actually been bitten by this and scrambling to find a solution as we are still running Ubuntu 18.04 on AWS OpsWorks (this is actually EoL and will be shut down next year).
Migrations steps are being planned but we still need to retain some services until we are done. This PPA worked just fine a couple of days ago, so paying Freexian just for the time we need for completing the migration seems kind of a stretch, for lack of a better word.
Does anyone know where to find a mirror of this (or even .deb files)? We could self host it for our own internal use until the migration is complete.
Thank you.
If so, why wouldn't you just pay?
I can see it being a question for the higher tiers where it's €10k or more.
Setting up a mirror would be trivial instead. I'm not asking by any means any support or time from him, even a ZIP file hosted on GitHub Releases (where bandwidth is "free") would've worked.
From there you could host your own private repo. I've used Aptly to do this easily.
Not sure why, my best guess is that Chef is automatically cleaning that up as a last step.
We have long had working builds for 20.04 but can’t run them on OpsWorks, and now we can’t build OpsWorks images.
This will get interesting. Any idea what service you’re transitioning to?
We're just working on containerizing everything and then migrate to ECS or EKS.
This is so ingrained that I've actually heard of project managers having specific post-shutdown plans to transition users who only then notice that something happened.
What I'm not clear on is the relationship(s) between:
* Canonical's LTS lifecycle/extended support scheme,
* the linked deb.sury.org repository,
* and https://www.freexian.com/lts/php/
It sounds like deb.sury.org is voluntarily halting _their_ PHP packaging for the EOL Ubuntu release, and recommending this alternative vendor Freexian instead (why not recommend Canonical ESM, do they not do PHP?)
The claim being that "it's not possible to build the packages any more" but I'm not sure why this would be, necessarily. More a technicality because the upstream distro will be gone/paywalled so a downstream PPA can't reasonably provide support? But then how is the other vendor doing it?
(Looking closer, Freexian's PHP packager appears to be the same guy running deb.sury.org so while it _is_ turtles all the way down, none of this seems unreasonable to me)
This is just the already known EOL policy acting as expected.
If people could still access the already-released free packages, then you'd have a point.