Nextcloud downloads are lacking xz compressed (LZMA) archive

[robert-scheck]

Steps to reproduce

When looking to https://download.nextcloud.com/server/releases/, there is a *.zip and a *.bz2 for each Nextcloud release, however no *.xz file. Using an xz compressed archive even reduces the download time (aside from the decompression time, because xz decompression is faster than bz2 decompression; see e.g. https://www.rootusers.com/gzip-vs-bzip2-vs-xz-performance-comparison/). A simple comparison of sizes using a self-generated xz archive (using xz -9):

-rw-r--r--. 1 rscheck users 29M 15. Feb 13:53 nextcloud-11.0.1.tar.xz
-rw-r--r--. 1 rscheck users 37M 15. Jan 17:32 nextcloud-11.0.1.tar.bz2
-rw-r--r--. 1 rscheck users 48M 15. Jan 17:32 nextcloud-11.0.1.zip

Expected behaviour

No nextcloud-11.0.1.tar.xz file available.

Actual behaviour

Only nextcloud-11.0.1.tar.bz2 and nextcloud-11.0.1.zip files available.

Server configuration

n/a

Client configuration

n/a

Logs

n/a

[MorrisJobke]

@LukasReschke @karlitschek Is this easily possible? Otherwise I would abandon it if it causes too much hassle on our side.

[karlitschek]

I'm not convinced is is worth it. Downloading a tar or zip should be no problem nowadays. IMHO

[LukasReschke]

I agree. I'd prefer not touching the packaging and release scripts just for this purpose.

[robert-scheck]

Well, could you then please replace the *.tar.bz2 by *.tar.xz simply like other common projects do? It is not just about you as upstream, but also about downstreams and decompressing a *.tar.xz requires less resources and is faster than *.tar.bz2.

[Glandos]

Using nextcloud-13.0.6.tar (extracted from the bzip2 official archive) on a Intel(R) Atom(TM) CPU D2550 @ 1.86GHz.

Zstd uses level 5 and bzip2 and xz use level 9.

Tool	Operation	user (s)	system (s)	elapsed (s)	max resident (kB)	output size (b)
zstd	decompress	1.41	1.58	3.01	3620	171776000
	compress	19.28	0.7	19.45	29156	45812437
bzip2	decompress	22.83	2.59	25.56	4924	171776000
	compress	99.99	0.94	101.43	8908	44633475
xz	decompress	6.2	1.83	8.06	67776	171776000
	compress	253.32	3.77	258.34	691528	34888648

So yes, from a user point-of-view, it is really useful to have something different than bzip2, because size is smaller and decompression speed is far higher. I guess that zstd is a bit too young to be available, but xz is a better solution for that use case.

Of course, it means updating a lot in the release process, and it also means that server need more power (and memory) for compression.

[robert-scheck]

So, could e.g. @LukasReschke or @karlitschek please re-open this, please? Even this suggestion is not as fancy as some other Nextcloud changes I still treat it as useful for users.

[skjnldsv]

Can we take a position here?
@MorrisJobke is it hard to add a new release archive format to the script? :)
If yes, then let's close it, It's maybe useful for some, but not worth the hassle imho 😉

[Glandos]

I wrote a small Ansible playbook to upgrade my installation. I started with the zip archive, since it's way faster than bz2 to extract. But unzip tool is missing so much feature, like --strip-components that I had to switch back to bz2. This is REALLY slow to extract. And it is bigger than xz. I understand that modifying a deployment script is hard, but it will clearly be a win-win for everyone.