It is true that these files can't be used for updating with the update component, and I agree they could lead people to doing wrong things like using them for updating.

The only thing they can be used for is to manually unpack them for repairing possibly missing or manipulated files by the right ones, using the package for exactly the same Joomla version as already installed.

Maybe they are a historical remainder from the old times before 3.4 or so when the extensions installer was used for updating the CMS.

The extensions installer still has the option to install or update from a folder to which such files have been unpacked before, so for extensions these package file formats still make sense. But not for the core, not in 4.x and not in 3.10. There is no "update from folder" option in the update component.

I think I remember there was a discussion about these files years ago, but unfortunately I don't remember where it was, here on GitHub or in Glip, and I don't remember why it was decided to keep them being built and offered on the downloads page.

Maybe @wilsonge remembers something?

P.S.: The reason why these file formats are not used by the update component and for extensions only when being unpacked manually into a folder is that we did not have a safe way to unpack them on the server on any kind of supported server operating system and without the need for additional PHP modules. Maybe this has changed meanwhile so we could use them when we implemented the unpacking without using operating system specific commands or PHP extensions of which we can't be sure they are available?

If we dont offer files in these formats then that PR would have a lot less code in it and would be easier to maintain. Right now there is a lot of code to detect that its not one of those files and then reject it. Which is pointless if we just dont build them in those formats

For other readers: With "that PR", the previous comment refers to PR #38707 .

For pull requests, Drone builds us update packages. There we have an update package of type ".tar.zst" which is also useless.

A pull request to address this is very simple - just want approval before doing it

A pull request to address this is very simple - just want approval before doing it

@brianteeman Does that refer to the complete issue or only to my comment about the drone packages for pull requests?

I was referring to changes in the build/build.php script

I haven't looked at how drone builds the pull request packages but I strongly suspect it will be just as easy

The build script already has options to exclude the useless packages (or in case of ".tar.zst" to include them):

https://github.com/joomla/joomla-cms/blob/4.2-dev/build/build.php#L40-L42

So for the nightlies and pull request packages it just would need to use the right options in drone.yml (which needs to be a signed commit, as far as I know). We recently had a similar change to not build the small patch packages which are known to be incomplete with the nightly builds.

And for building release packages it would mean to use the --exclude-gzip and --exclude-bzip2 options and update our releasing documentation accordingly.

Problem is that the above mentioned parameters of the build script do not allow to control the installation and update packages independently, i.e. exclude-gzip for the update packages but not for the installation packages. Easy fix could be to apply these parameters only to the update packages and ignore them for the installation packages (or in case of the --include-zstd always set it for the installation packages) so that the installation packages are always build for all file formats and the update packages depending on the parameters.

just needs to delete the gzip and bziup2 lines from the update/upgrade sections and keep them in the full section

... and the same for the zstd line, and update the help text accordingly so it's clear that the --exclude-gzip and --exclude-bzip2 and --include-zstd parameters are only relevant for the full installation packages.

as I said - simple pr to create

For consistency we should remove the stuff not only for the update packages but also for the smaller patch packages, even if we currently don't build them.

Patch packages:

https://github.com/joomla/joomla-cms/blob/4.2-dev/build/build.php#L532-L547

https://github.com/joomla/joomla-cms/blob/4.2-dev/build/build.php#L559-L565

Update packages:

https://github.com/joomla/joomla-cms/blob/4.2-dev/build/build.php#L626-L640

https://github.com/joomla/joomla-cms/blob/4.2-dev/build/build.php#L650-L656

I think I remember there was a discussion about these files years ago, but unfortunately I don't remember where it was, here on GitHub or in Glip, and I don't remember why it was decided to keep them being built and offered on the downloads page.
Maybe @wilsonge remembers something?

Not aware of it. For 3.7 onwards it's probably just cruft obviously specifically for upgrade packages only. We probably still want to give people options for the other stuff. Although probably still value for the full packages

dont build and store files we dont need - save the planet

PR #39567

Closing as having a pull request. See #39567 .