(In reply to Rodney Baker from comment #0)
> A new dependency on btrfsprogs has been added to virt-v2v on 18/04/2024.
> This causes an error when doing a zypper dup on TW systems not using btrfs.
> I do not use and have no intention of using btrfs - it is really necessary
> for this to be a hard dependency rather than a "recommend"?

It is less about what your host uses but rather what the guest VMs use that
you are trying to convert. If you are trying to convert a Xen VM to KVM that
uses btrfs which is the default for Leap and SLE products, then you need
btrfsprogs.

There is no "requires" for e2fsprogs, ntfsprogs or any other similar file system packages - surely the same applies to them if trying to convert an image that uses ext[2,3,4] or ntfs? Why should btrfsprogs be any different? "Recommends" seems to make more sense here.

(In reply to Rodney Baker from comment #2)
> There is no "requires" for e2fsprogs, ntfsprogs or any other similar file
> system packages - surely the same applies to them if trying to convert an
> image that uses ext[2,3,4] or ntfs? Why should btrfsprogs be any different?
> "Recommends" seems to make more sense here.

A virt-v2v that does not work for guests with btrfs is a non-functional virt-v2v.

virt-v2v is only useful if it can convert guests successfully. To do that it needs tools on the host.

If there is an issue when upgrading virt-v2v for some reason, that issue needs to be solved.

With virt-v2v it's do (install virt-v2v) or do not (do not install virt-v2v), there is no try.

Well then it should depend on e2fsprogz, ntfsprogs and any other filesystem that a guest may contain/use that might need to be converted. Why should btrfs be treated any differently than any other commonly-used filesystem? Enterprises do not use only guests that run btrfs and may need to convert guests that do not use btrfs. If you're going to have a hard dependency on tools for one filesystem, why not the rest?

Surely this can be dealt with through documentation and/or a warning: "You must have the relevant filesystem tools installed for the filesystems used by the guest VM you are about to convert", or words to that effect.

(In reply to Rodney Baker from comment #5)
> Surely this can be dealt with through documentation and/or a warning: "You
> must have the relevant filesystem tools installed for the filesystems used
> by the guest VM you are about to convert", or words to that effect.

No, It would be almost impossible for users to track down the nest of runtime requirements.

If you don't want virt-v2v, do not install it.

If you want a functional virt-v2v, you need all required runtime dependencies, or the conversions _will_ fail.

(In reply to Claudio Fontana from comment #6)
> (In reply to Rodney Baker from comment #5)
> > Surely this can be dealt with through documentation and/or a warning: "You
> > must have the relevant filesystem tools installed for the filesystems used
> > by the guest VM you are about to convert", or words to that effect.
> 
> No, It would be almost impossible for users to track down the nest of
> runtime requirements.
> 
> If you don't want virt-v2v, do not install it.
> 
> If you want a functional virt-v2v, you need all required runtime
> dependencies, or the conversions _will_ fail.

Then be consistent and add "requires" for e2fsprogs, ntfsprogs and xfsprogs as well. After all, as you said, "If you want a functional virt-v2v, you need all required runtime dependencies, or the conversions _will_ fail."

The latest virt-v2v has the dependencies removed for file system tools but
instead has a new dependency on libguestfs which in turn requires
libguestfs-appliance. This effectively keeps all requirements for file system
tools (btrfsprogs, e2fsprogs, etc.) for virt-v2v to be installed and used.