<html><head></head><body bgcolor="#ffffff" text="#555555" link="#a1a1a1" vlink="#a1a1a1"><div>Am Dienstag, den 28.11.2017, 23:13 +0100 schrieb Hilko Bengen:</div><blockquote type="cite"><pre>libguestfs is designed to handle disk images of virtual machines and it
makes sense to include at least support for common filesystems. You and
I may not particularly like the filesystem, but btrfs is one of the more
commonly used filesystems.
</pre></blockquote><div><br></div><div>See e.g. <a href="https://btrfs.wiki.kernel.org/index.php/Main%5FPage">https://btrfs.wiki.kernel.org/index.php/Main%5FPage</a></div><div>„Not too many companies have said that they are using Btrfs in production…“</div><div><br></div><blockquote type="cite"><pre>
See [1] for why the binary packages built from the libguestfs source
packages are split the way they are right now.
</pre></blockquote><div><br></div><div>But size is not the only criteria - see below.</div><blockquote type="cite"><pre>
<blockquote type="cite">
There are systems which explicitly exclude btrfs from setup.
</blockquote>

I'm not sure I follow: Do you mean that some sort of policy
forbids/prevents installation of anything btrfs-related?
</pre></blockquote><div><br></div><div>**YES**</div><div>I'm maintaining an mid-size installation. For these systems 'btrfs-tools' is explicitly removed:</div><div>  - not used, because I rely on ext4 and mdraid</div><div>  - limiting the installed packages is improving the security (reducing surface)</div><div>  - it has had introduced a boot delay (at this time trusty was used, not retested actually).</div><div><br></div><div>In my opinion a package maintainer shouldn't nail a dependency if the package may work without.</div><div>It is simple discrete mathematics that he couldn't overview the exponentially growing diversity of installations 😉</div><div><br></div><div><br></div><div>Best Regards,</div><div><br></div><div>H.-DIrk Schmitt</div></body></html>