<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 29 March 2017 at 20:42, Stefan Agner <span dir="ltr"><<a href="mailto:stefan@agner.ch" target="_blank">stefan@agner.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif"><span class="">
<p>On 2017-03-29 08:41, Burton, Ross wrote:</p>
<blockquote type="cite" style="padding:0 0.4em;border-left:#1010ff 2px solid;margin:0">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 28 March 2017 at 23:45, Stefan Agner <span><<a href="mailto:stefan@agner.ch" target="_blank">stefan@agner.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id="m_-8483252579589999036:yn" class="m_-8483252579589999036a3s m_-8483252579589999036aXjCH m_-8483252579589999036m15b171ab2ecb0014">@@ -30,8 +30,8 @@ PACKAGES =+ "util-linux-agetty util-linux-fdisk util-linux-cfdisk util-linux-sfd<br> <span> util-linux-swaponoff util-linux-losetup util-linux-umount \<br> util-linux-mount util-linux-readprofile util-linux-uuidd \<br> </span> util-linux-uuidgen util-linux-lscpu util-linux-fsck.cramfs util-linux-fsck \<br> - util-linux-blkid util-linux-mkfs util-linux-mcookie util-linux-reset \<br> - util-linux-lsblk util-linux-mkfs.cramfs util-linux-fstrim \<br> + util-linux-blkdiscard util-linux-blkid util-linux-mkfs util-linux-mcookie \<br> + util-linux-reset util-linux-lsblk util-linux-mkfs.cramfs util-linux-fstrim \<br> util-linux-partx util-linux-hwclock util-linux-mountpoint \<br> util-linux-findfs util-linux-getopt util-linux-sulogin util-linux-prlimit"</div>
</blockquote>
</div>
<br>We're growing a lot of packages containing a single binary. Would it be sensible to group them into "file system tools", "process tools", etc?</div>
</div>
</blockquote>
</span><p>Not sure if such a high level grouping is helpful. Just because an image uses one fs utility, does not mean the others are used too. There might be some potential on a lower level (e.g. <span>util-linux-mkfs.cramfs and <span>util-linux-fsck.cramfs).</span></span></p>
<p>Is having lots of single binary packages an issue? I guess package management data adds some space overhead? In my case, I build a image without package metadata, so I guess there is no overhead for the final image (for the final image).</p></div></blockquote><div><br></div><div>I have no hard data on this but we are struggling with oe-selftests taking too long (we're talking 4-10 hour runs and personally I think we should be running many more tests than we currently do). </div><div><br></div><div>The time it takes to boot an image and run the test won't be affected by this patch, but I'm guessing it does increase the packaging and rootfs generation time by a little bit. Multiply that by the number of images we build and add it to all the other "little bits" of time...</div><div><br></div><div>Would be nice to have some hard data on this though -- I don't really know if this is the place to optimize.</div><div><br></div><div>Jussi <br></div><div> </div></div></div></div>