#883020 Debian Bug Report: libguestfs0 should not depend on btrfs-progs

Package:
libguestfs0
Source:
libguestfs
Description:
guest disk image management system - shared library
Submitter:
"H.-Dirk Schmitt"
Date:
2017-11-29 18:27:06 UTC
Severity:
normal
#883020#5
Date:
2017-11-28 21:14:22 UTC
From:
To:
libguestfs0 should not depend on btrfs-progs.
There are systems which explicitly exclude btrfs from setup.

Is there a hard reason that a "Recommends" is not enough ?

#883020#10
Date:
2017-11-28 22:13:00 UTC
From:
To:
* H.-Dirk Schmitt:

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.

See [1] for why the binary packages built from the libguestfs source
packages are split the way they are right now.
forbids/prevents installation of anything btrfs-related?

Cheers,
-Hilko

[1] https://rwmj.wordpress.com/2014/03/20/analysis-of-the-size-of-libguestfs-dependencies/

#883020#15
Date:
2017-11-29 15:00:10 UTC
From:
To:
Am Dienstag, den 28.11.2017, 23:13 +0100 schrieb Hilko Bengen:

See e.g. https://btrfs.wiki.kernel.org/index.php/Main%5FPage
„Not too many companies have said that they are using Btrfs in
production…“

But size is not the only criteria - see below.

**YES**
I'm maintaining an mid-size installation. For these systems 'btrfs-
tools' is explicitly removed:
  - not used, because I rely on ext4 and mdraid
  - limiting the installed packages is improving the security (reducing
surface)
  - it has had introduced a boot delay (at this time trusty was used,
not retested actually).

In my opinion a package maintainer shouldn't nail a dependency if the
package may work without.
It is simple discrete mathematics that he couldn't overview the
exponentially growing diversity of installations 😉


Best Regards,

H.-DIrk Schmitt

#883020#20
Date:
2017-11-29 16:13:01 UTC
From:
To:
* H.-Dirk Schmitt:
whatever it is called these days) are based upon BTRFS.

If you really wish to reduce the attack surface imposed by a filesystem
implementation, you'll want to get rid of the kernel component, i.e.
you'll ship custom kernels or use module blacklisting. This means that
you are already working with distribution tools and I suggest using
equivs or similar to provide a dummy btrfs-progs package.

Cheers,
-Hilko

#883020#25
Date:
2017-11-29 16:26:18 UTC
From:
To:
Am Mittwoch, den 29.11.2017, 17:13 +0100 schrieb Hilko Bengen:

Oops - I thought I'm using the Debian Bug Tracker 😉

You are right - there are a lot of different solutions for different
problems ☺
The justification for the exclusion of btrfs-tools in our organisation
was just provided to give you some ideas about why somebody can't
deploy btrfs-tools.

For my installations I resolved the conflict already by adding an
'Provides:' clause to an organisational meta package.

The intention to report it here was to avoid this troubles for other
users and improve the package quality.


Best Regards,

H.-Dirk Schmitt

#883020#30
Date:
2017-11-29 18:22:15 UTC
From:
To:
* H.-Dirk Schmitt:

Sure, thanks.

I am not going make any changes to the package but I'm going to leave
the bug report open.

Cheers,
-Hilko