saucy initramfs ballooned, causing bootspeed regression. Ecryptfs-utils is now minimal?

Difference between -2 and -3 was mostly removing icu again, so that's unrelated to udev:

@@ -1091,13 +1091,12 @@
 lib/x86_64-linux-gnu/libexpat.so.1
 lib/x86_64-linux-gnu/libext2fs.so.2
 lib/x86_64-linux-gnu/libfuse.so.2
-lib/x86_64-linux-gnu/libgcc_s.so.1
 lib/x86_64-linux-gnu/libgcrypt.so.11
 lib/x86_64-linux-gnu/libglib-2.0.so.0
 lib/x86_64-linux-gnu/libgpg-error.so.0
 lib/x86_64-linux-gnu/libkmod.so.2
 lib/x86_64-linux-gnu/libm.so.6
-lib/x86_64-linux-gnu/libntfs-3g.so.84
+lib/x86_64-linux-gnu/libntfs-3g.so.841
 lib/x86_64-linux-gnu/libpcre.so.3
 lib/x86_64-linux-gnu/libply.so.2
 lib/x86_64-linux-gnu/libply-splash-core.so.2
@@ -1180,15 +1179,12 @@
 usr/lib/x86_64-linux-gnu/libfreetype.so.6
 usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0
 usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
+usr/lib/x86_64-linux-gnu/libgraphite2.so.3
 usr/lib/x86_64-linux-gnu/libharfbuzz.so.0
-usr/lib/x86_64-linux-gnu/libicudata.so.48
-usr/lib/x86_64-linux-gnu/libicule.so.48
-usr/lib/x86_64-linux-gnu/libicuuc.so.48
 usr/lib/x86_64-linux-gnu/libpango-1.0.so.0
 usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0
 usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0
 usr/lib/x86_64-linux-gnu/libpixman-1.so.0
-usr/lib/x86_64-linux-gnu/libstdc++.so.6
 usr/lib/x86_64-linux-gnu/libthai.so.0
 usr/lib/x86_64-linux-gnu/libX11.so.6
 usr/lib/x86_64-linux-gnu/libXau.so.6

Setting to incomplete now, seems this was a red herring and caused by having "MODULES=dep" in /etc/initramfs-tools/initramfs.conf (we default to "most").

I can only reproduce the 16MB initrd size using MODULES=dep configuration change in initramfs tools. Referring to QA to confirm how the older results are being run.

Ok after much poking we can say that what has occurs is that the initrd has bloated. Bloated because plymouth is now in the initrd. This has occured because cryptsetup is now always installed after an install. We expect this to be removed if not needed, but it is not being so removed.

It seems like ecryptfs-utils and hence cryptsetup are now in task:minimal [1], while they previously were not [2].
Also comparing raring minimal seed [3] with saucy [4], reveals that ecryptfs-utils is now in minimal.
I don't think ecryptfs-utils should be pulled into minimal.

[1] http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/saucy/daily-live-20130521.log
Resolving minimal dependencies ...
! Promoted ecryptfs-utils from d-i-requirements to minimal to satisfy adduser

[2] http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/saucy/daily-live-20130520.log

[3] http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.raring/minimal

[4] http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.saucy/minimal

<xnox> i see that it moved into minimal on 20130521 http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/saucy/daily-live-20130521.log
<cjwatson> adduser wasn't in minimal in raring for some reason
<cjwatson> Ah, it was in required, which is really where it belongs IMO
<cjwatson> But required doesn't follow Recommends
<cjwatson> So I guess something in required dropped a Depends: adduser
<cjwatson> Well, I dunno, adduser in minimal vs. required is OK actually
<pitti> xnox: my gut feeling is that adduser should only suggest ecryptfs-utils
<cjwatson> TBH this is basically that the Recommends was incorrectly not noticed in raring
<cjwatson> So I'd say adduser should be left where it is and drop the Recommends to Suggests
<xnox> ack. will upload.

This bug was fixed in the package adduser - 3.113+nmu3ubuntu2

---------------
adduser (3.113+nmu3ubuntu2) saucy; urgency=low

  * Move ecryptfs-utils from recommends, to suggests. (LP: #1188108)
    Adduser has moved from required to minimal set, and thus started to
    pull ecryptfs-utils and cryptsetup into minimal installs, which is an
    undesired effect.
 -- Dmitrijs Ledkovs <email address hidden> Fri, 07 Jun 2013 11:24:08 +0100