Re: build.sh sets with xz (was Re: vfs cache timing changes)

[Greg Troxel <gdt%lexort.com@localhost>]

Martin Husemann <martin%duskware.de@localhost> writes:

> On Fri, Sep 13, 2019 at 06:59:42AM -0400, Greg Troxel wrote:
>> I'd like us to keep somewhat separate the notions of:
>> 
>>   someone is doing build.sh release
>> 
>>   someone wants min-size sets at the expense of a lot of cpu time
>> 
>> 
>> I regularly do build.sh release, and rsync the releasedir bits to other
>> machines, and use them to install.  Now perhaps I should be doing
>> "distribution", but sometimes I want the ISOs.
>
> The default is MKDEBUG=no so you probably will not notice the compression
> difference that much.

I don't follow what DEBUG has to do with this, but that's not important.

> If you set MKDEBUG=yes you can just as easily set USE_XZ_SETS=no
> (or USE_PIGZGZIP=yes if you have pigz installed).

Sure, I realize I could do this.  The question is about defaults.

> The other side of the coin is that we have reproducable builds, and we
> should not make it harder than needed to reproduce our official builds.

It should not difficult or hard to understand, which is perhaps
different than defaults.

> But ... it already needs some settings (which we still need to document
> on a wiki page properly), so we could also default to something else
> and force maximal compressions via the build.sh command line on the
> build cluster.

I could see

MKREPRODUCILE=yes

causing defaults of various things to be a particular way, and perhaps
letting XZ default to no otherwise.  I would hope that what
MKREPRODUCILE=yes has to set is not very many things, but I haven't kept
up.