Author: anonym Date: To: The Tails public development discussion list Subject: Re: [Tails-dev] Please review some vagrant optimizations [was:
Shipping a 686-pae kernel]
10/09/12 15:51, intrigeri wrote: > anonym wrote (10 Sep 2012 13:40:31 GMT) :
>> 06/09/12 11:51, intrigeri wrote:
>>> Also, FWIW my libvirt -based build VM is given 6 GiB, no swap,
>>> builds fine inside a 6GB ramdisk, so perhaps the Vagrant build
>>> process could be optimized a bit?
>
>> Which optimizations do you use?
>
> None.
>
> I have that, though, in my /etc/live/build.conf:
>
> LB_CACHE_PACKAGES="false"
>
> (Caching packages is useless once you have a caching proxy do
> it already.)
That alone saves ~1 GiB, which is pretty damn nice. Added in commit
17cea97, which also removes bootstrap package caching.
>> Both seem like great improvements to me both memory-wise and
>> (incidentally) time-wise. I've implemented this in feature/vagrant:
>> the aufs trick is always used when building in RAM, and the
>> bootstrap cache can be controlled with
>> TAILS_BUILD_OPTIONS=(no)cache, (enabled by default), and the
>> TAILS_BUILD_OPTIONS=cleanall option also clears the bootstrap
>> packages + stage cache. The documentation about this also pushed
>> into that branch.
>
> I find it a bit scary not to clean the bootstrap stage by default.
>
> I find "dev-time -only" optimizations scary in general,
> both because sometimes one forgets to disable them when building
> a final image (see the last RC with gzip'd SquashFS),
True. The "gzip'd SquashFS in last RC" issue was due to the Vagrant
implementation assuming that RC/final releases are built from the
stable/testing branches only, when in reality they are built from
checked out tags (at least by me). I just fixed that in commit a51a797.
The `cache` option could be disabled in the same situation but...
In commit 38c8394 I've made it so that 'cleanall' is enforced for all
release builds (this also cleans the cached wiki, which I feel is
necessary) which makes the above a non-issue.
> and because it may result in subtle differences between the resulting
> images, that are very hard to track and understand.
For the record, I used bootstrap stage caching in my personal build
script for ~1 year (until I started using vagrant). I did clean it
regularly (and before building a new release, and whenever I experienced
"unexplainable" issues) so I wasn't completely mad, I think. :)
Should I take this as if you don't want bootstrap stage caching as an
option to be available at all? Or would you be fine if it's just
disabled by default (+ a warning in the documentation)? I.e. would you
be comfortable with other developers using this option in the fashion I
used it previously, as described above?
