Re: Seeking feedback on a meta package builder
Hi Alex,
On Wed, Jun 02, 2021 at 05:07:16PM +0200, Alex Muntada wrote:
> This reminded me of my using of ccache and eatmydata in sbuild.
> They may not be relevant for the context of mdbp depending on
> the resources available for building, indeed.
>
> I'm pretty fond of them because they speed up a lot some heavy
> builds on my laptop, therefore I'd appreciate to have some speed
> toggles in any service where I want to send those builds to.
TL;DR: Don't add speedup flags, make it fast by default.
I don't think speedups are relevant for any of the prospective users.
ccache either needs a small set of packages or a huge cache directory to
perform well. For many use cases (rebootstrap in particular), the
toolchain changes frequently, so the cache would have to be invalidated
very often. Most mdbp users would work with at least hundreds of
packages.
As for eatmydata, I don't think that adding this as toggle is useful.
After all, we don't want eatmydata to have any influence on the build.
So a mdbp backend can just unconditionally enable it if it makes sense
without concerning a prospective user of the API.
A very reliably alternative to eatmydata is building on tmpfs with a
huge swap partition. It also performs significantly better than
eatmydata in my experience as it fully eliminates the need to write to
disk a lot of the time.
When you use pbuilder's "extract tarball" approach or a type=file
schroot with sbuild on a tmpfs (optionally speeding things up by using
zstd as compressor), the chroot setup can feel quite instantaneous.
Ultimately, speedups should just become the default for the benefit of
everyone rather than opt-in. If I remember correctly, pbuilder now
defaults to disable man database generation via debconf, which also
provides a useful speedup.
Helmut
Reply to: