From hp@ge@@on@g|thub @end|ng |rom gm@||@com  Wed Sep 13 02:05:25 2023
From: hp@ge@@on@g|thub @end|ng |rom gm@||@com (=?UTF-8?B?SGVydsOpIFBhZ8Oocw==?=)
Date: Tue, 12 Sep 2023 17:05:25 -0700
Subject: [Rd] 
 FYI: daily R source tarballs from ETH: *.xz instead of *.bz2)
In-Reply-To: <f84b708a-6ddd-4c02-a97c-8a1331768444@stats.ox.ac.uk>
References: <25851.9552.398085.384361@stat.math.ethz.ch>
 <27378572-a2e2-eb29-1e7d-9c8d7020bd3a@gmail.com>
 <f84b708a-6ddd-4c02-a97c-8a1331768444@stats.ox.ac.uk>
Message-ID: <c31fd49d-3249-881b-64e5-a6ad9895be4e@gmail.com>

On 9/11/23 22:39, Prof Brian Ripley wrote:

> On 09/09/2023 01:56, Herv? Pag?s wrote:
>> Hi Martin,
>>
>> Sounds good. Are there any plans to support the xz compression for
>> package source tarballs?
>
> What makes you think it is not supported?

I guess because I've never seen source tarballs distributed as .xz files 
but it's good to know that 'R CMD build' and 'R CMD INSTALL' support that.

So let me reformulate my question: do CRAN have any plans to switch from 
.tar.gz to .xz for the distribution of source tarballs? Is this 
something that tools like write_PACKAGES(), available.packages(), and 
install.packages() would be able to handle? Would they be able to handle 
a mix of .tar.gz and .xz packages? (Which would be important for a 
smooth transition from .tar.gz to .xz across CRAN/Bioconductor.)

I'm just trying to get a sense if the effort to reduce bandwidth will go 
beyond the distribution of R source snapshots.

Thanks,

H.

-- 
Herv? Pag?s

Bioconductor Core Team
hpages.on.github at gmail.com

	[[alternative HTML version deleted]]



[Rd] FYI: daily R source tarballs from ETH: *.xz instead of *.bz2)
=?UTF-8?B?SGVydsOpIFBhZ8Oocw==?=