bug#79720: libparted: wrong metadata length with empty GPT partition table

Package: parted
Version: 3.6
Severity: minor

Dear maintainers,

When libparted reads an existing empty GPT partition table, it wrongly 
creates the main and backup virtual metadata partitions with a length 
based on GPT_DEFAULT_PARTITION_ENTRIES (128) instead of the actual 
partition table length based on NumberOfPartitionEntries in the GPT 
header. Only after an active partition is added (either read from the 
on-disk partition table or new), the metadata partitions have the 
correct length.

Looking at libparted/label/gpt.c, it seems that gpt_read() initializes 
the partition table object with GPT_DEFAULT_PARTITION_ENTRIES and does 
not trigger an update of metadata and free space after parsing the GPT 
header but only when partitions are added.

(My use case is with partman, the Debian installer partitioning tool 
based on libparted. I need to check whether the current GPT metadata 
would overlap with U-Boot location for Allwinner sunxi SoCs starting at 
offset 8KiB (sector 16). A GPT partition table with a maximum length of 
56 entries can be created with gdisk and ends at sector 15 so is 
compatible with U-Boot for sunxi. But when the GPT partition table is 
empty, the reported metadata length is inaccurate.)

As a workaround, is there a simple reliable way using libparted API to 
update metadata without altering the state of the partition table ?

Otherwise, what is the best place and way to fix this in libparted, in 
other word make sure metadata and free space are properly updated when 
the partition table is empty ?
IIUC it involves _disk_push_update_mode() and _disk_pop_update_mode() 
which can be called only in libparted/disk.c.