I have been voluntarily maintaining a Chocolatey package for ActivePerl for some time now (Chocolatey is a community based software manager for Windows, to some extend comparable to Homebrew for MacOS). The ActivePerl Chocolatey package is quite popular e.g. the v5.28 has been installed over 40k times.
A Chocolatey package is not a real package in the classical way. In practice a “package” is just a PowerShell script that downloads the actual software package from the software vendors site and then installs it. The package maintainer (that is: me) provides the required metadata such as installer download url, installer checksum, installer arguments etc.
Previously creating a Chocolatey recipe for the ActivePerl was a breeze. However, starting from v5.28, the download content for the community edition is not permanent anymore. That is, the community edition seems to be a weekly-build and the content checksum changes weekly. The Chocolatey packaging rules expect a hard-coded checksum for each version in the recipe. This makes it very problematic to maintain the Chocolatey install script.
Theoretically, I could release a new Chocolatey version on weekly basis. However, because there would always be a delay between the actual weekly release and the Chocolatey package update (including the moderation delay), the installer would break time to time (i.e. when the last weeks build is not available anymore but the Chocolatey package has not been updated yet). Another option would be to mirror the weekly releases but this is in my understanding not permitted by the license.
Now, I wonder if it would be possible for ActiveState to have a some semi-permanent download url for the weekly releases? E.g. so that the weekly builds would have distinguishable file-name and the old weekly release would be available for download for some time. Or maybe you have some other ideas, how to make this work?
You’re right that ActivePerl now gets regular updates but there’s a way to use the ActiveState platform and its companion CLI, the state tool, to do what you want without even downloading the installer. First, go get yourself an account at https://platform.activestate.com/ if you haven’t already. Then browse to https://platform.activestate.com/ActiveState/ActivePerl-5.28/ and click the “Fork it” button at the top of the page there. It will give you the option to fork it into your personal organization which was created for you when you signed up, so create the project there. That will give you a frozen copy of ActivePerl as it appears at that time.
To install this ActivePerl from a script, the easiest way is to use the state tool CLI. Installation instructions including a handy powershell install script for this can be found here: https://platform.activestate.com/dev-tools. Once you have this installed (which may be worth a chocolatey package itself) you can run:
state activate --default <your-org-name>/ActivePerl-5.28
Which will install the frozen version of ActivePerl-5.28 you created. The platform will also handily generate one-liner install scripts which will install both the state tool and your project in one go, e.g.:
If you want your ActivePerl to look slightly more official in the script, one other option for getting a frozen build is to pick a particular commit of the official ActivePerl project to install. Platform projects have a history, and each update generates a commit to that history. You can view the commits for a project from the History tab for the project on the platform. To install today’s build of ActivePerl-5.28 with the state tool for example, you would run:
state activate --default ActiveState/ActivePerl-5.28#bce91069-bc17-473e-9d3c-9f1e1ad5c6fd
Every time you run that command you are guaranteed to get the exact same build, which should support your use case.
Hopefully this gives you a way forward, let us know if you have any further questions!