[PATCH common] options: Require libguestfs >= 1.42.
Libguestfs itself is obviously now >= 1.42. In virt-v2v we made a similar change upstream to require libguestfs >= 1.42. Therefore the ifdefs are no longer required. --- options/decrypt.c | 5 ----- options/options.c | 4 ---- 2 files changed, 9 deletions(-) diff --git a/options/decrypt.c b/options/decrypt.c index 683cf5ed4..32ef29fd6 100644 --- a/options/decrypt.c +++ b/options/decrypt.c @@ -85,12 +85,7 @@ inspect_do_decrypt (guestfs_h *g, struct key_store *ks) if (type && STREQ (type, "crypto_LUKS")) { char mapname[32]; make_mapname (partitions[i], mapname, sizeof mapname); - -#ifdef GUESTFS_HAVE_LUKS_UUID CLEANUP_FREE char *uuid = guestfs_luks_uuid (g, partitions[i]); -#else - const char *uuid = NULL; -#endif CLEANUP_FREE_STRING_LIST char **keys = get_keys (ks, partitions[i], uuid); assert (guestfs_int_count_strings (keys) > 0); diff --git a/options/options.c b/options/options.c index abdcbae5b..63221ea32 100644 --- a/options/options.c +++ b/options/options.c @@ -140,12 +140,10 @@ add_drives_handle (guestfs_h *g, struct drv *drv, size_t drive_index) ad_optargs.bitmask |= GUESTFS_ADD_DRIVE_OPTS_DISCARD_BITMASK; ad_optargs.discard = drv->a.discard; } -#ifdef GUESTFS_ADD_DRIVE_OPTS_BLOCKSIZE_BITMASK if (drv->a.blocksize) { ad_optargs.bitmask |= GUESTFS_ADD_DRIVE_OPTS_BLOCKSIZE_BITMASK; ad_optargs.blocksize = drv->a.blocksize; } -#endif r = guestfs_add_drive_opts_argv (g, drv->a.filename, &ad_optargs); if (r == -1) @@ -179,12 +177,10 @@ add_drives_handle (guestfs_h *g, struct drv *drv, size_t drive_index) ad_optargs.bitmask |= GUESTFS_ADD_DRIVE_OPTS_SECRET_BITMASK; ad_optargs.secret = drv->uri.password; } -#ifdef GUESTFS_ADD_DRIVE_OPTS_BLOCKSIZE_BITMASK if (drv->uri.blocksize) { ad_optargs.bitmask |= GUESTFS_ADD_DRIVE_OPTS_BLOCKSIZE_BITMASK; ad_optargs.blocksize = drv->uri.blocksize; } -#endif r = guestfs_add_drive_opts_argv (g, drv->uri.path, &ad_optargs); if (r == -1) -- 2.25.0
On Tuesday, 10 March 2020 14:07:56 CET Richard W.M. Jones wrote:
Libguestfs itself is obviously now >= 1.42. In virt-v2v we made a similar change upstream to require libguestfs >= 1.42. Therefore the ifdefs are no longer required. ---
Even if we accept this patch, there is the larger unsolved issue of the branch strategy for libguestfs-common: there will be for sure "stable" fixes, and bumping the common submodule in libguestfs and virt-v2v will pull in also new features, possibly requiring new APIs (like this patch shows) or internal API changes in the common parts. How do we deal with that? -- Pino Toscano
On Tue, Mar 10, 2020 at 05:00:00PM +0100, Pino Toscano wrote:
On Tuesday, 10 March 2020 14:07:56 CET Richard W.M. Jones wrote:
Libguestfs itself is obviously now >= 1.42. In virt-v2v we made a similar change upstream to require libguestfs >= 1.42. Therefore the ifdefs are no longer required. ---
Even if we accept this patch, there is the larger unsolved issue of the branch strategy for libguestfs-common: there will be for sure "stable" fixes, and bumping the common submodule in libguestfs and virt-v2v will pull in also new features, possibly requiring new APIs (like this patch shows) or internal API changes in the common parts.
How do we deal with that?
I guess we can add branches as needed to libguestfs-common? (eg. stable-libguestfs-1.42, stable-v2v-1.42) Is there a reason that wouldn't work? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
On Tuesday, 10 March 2020 17:33:41 CET Richard W.M. Jones wrote:
On Tue, Mar 10, 2020 at 05:00:00PM +0100, Pino Toscano wrote:
On Tuesday, 10 March 2020 14:07:56 CET Richard W.M. Jones wrote:
Libguestfs itself is obviously now >= 1.42. In virt-v2v we made a similar change upstream to require libguestfs >= 1.42. Therefore the ifdefs are no longer required. ---
Even if we accept this patch, there is the larger unsolved issue of the branch strategy for libguestfs-common: there will be for sure "stable" fixes, and bumping the common submodule in libguestfs and virt-v2v will pull in also new features, possibly requiring new APIs (like this patch shows) or internal API changes in the common parts.
How do we deal with that?
I guess we can add branches as needed to libguestfs-common? (eg. stable-libguestfs-1.42, stable-v2v-1.42)
Thinking about it, also master-v2v might be needed, unless libguestfs-common/master keeps the support for libguestfs down to the version that virt-v2v/master requires. Other than that, the idea seems OK; I'm just worried about the need for multiple cherry-picks/submodule bumps just for simple bug fixes in libguestfs-common :-/ -- Pino Toscano
participants (2)
-
Pino Toscano -
Richard W.M. Jones