Web lists-archives.com

Re: pro-tip: preinstall debhelper in your sbuild




On Fri, Mar 24, 2017 at 05:49:52PM +0500, Andrey Rahmatullin wrote:
> On Fri, Mar 24, 2017 at 01:46:31PM +0100, Adam Borowski wrote:
> > Thought I'd share a trick I'm using: as debhelper's dependencies chain became
> > really fat, you can gain a drastic speed-up (especially for small packages)
> > by preinstalling debhelper into your base sbuild/pbuilder/etc image.
> What if debhelper drops a dep?

Well, then indeed you'd miss a missing B-D.  That's a concern as sbuild
doesn't use debfoster anymore; autoremove will still usually catch this.

On the other hand, debhelper getting slimmer as opposed to fatter is quite a
rare occurence; you do refresh your chroots from time to time (don't you?);
and as long as at least some buildds / rebuilds use the whole process the
regression won't go unnoticed.  It's far more likely to make an existent
package FTBFS than to affect a new upload.

select sum(install_time),sum(build_time) from builds where status='successful';
  13⎖586⎖617 53⎖261⎖306
Over ¼!

debootstrap --variant=buildd --include=eatmydata stretch . http://apt.angband.pl:3142/debian
time chroot . eatmydata apt install --no-install-recommends -y debhelper
real	1m13.545s
user	0m30.420s
sys	0m11.735s
(for a realistic test, there were two running sbuild instances at the time,
as usual for this box, both were compiling (pcre2 and llvm-toolchain-3.9))

select count(*)*73.545 from builds where status='successful';
  7⎖483⎖350

That's massive.

Obviously, the above comparison doesn't apply to running on tmpfs with gobs
of memory, but you optimize cases that need help the most...

<troll>
Or use "goodbye" for debhelper-less speed. :þ
</troll>

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄⠀⠀⠀⠀ preimage for double rot13!