[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Seeking feedback on a meta package builder



Quoting Helmut Grohne (2021-06-03 07:41:07)
> 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.

I think those are more accurately described as "trade-off flags" and 
that your argument is to limit the scope of tools instead of supporting 
a wider variety of needs.

Most notably, ccache is a tradeoff between speed+cost of network 
bandwidth versus local disk space.

I agree that any speedup without tradeoff should be just enabled by 
default.

And sure, a frontend wrapper tool may not need to care about some 
options, if possible to configure the backend independently.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: signature


Reply to: