[parted-devel] bug#56996: gpt_partition_set_system possible regression

[Brian C. Lane]

On Fri, Aug 05, 2022 at 09:14:26AM +0200, Mathieu Othacehe wrote:
> 
> Hello,
> 
> In GNU Guix we are using GNU Parted via Guile-Parted bindings. Upgrading
> from Parted 3.4 to Parted 3.5 we discovered a possible regression.
> 
> We are creation a new partition on a gpt disk this way:
> 
> ped_partition_new (ext4)
> ped_partition_set_flag (PED_PARTITION_BIOS_GRUB)
> ped_partition_set_system (ext4)
> 
> Since 15c49ec04f7eaff014d2e1eddd0aecf4150db63d, ped_partition_set_system
> forces the gpt_part_data->type to PARTITION_LINUX_DATA_GUID, whereas it
> used to conserve the gpt_part_data->type to PARTITION_BIOS_GRUB_GUID.
> 
> This forces us to reverse the ped_partition_set_system and
> ped_partition_set_flag call order. Is that expected?

I'm trying to recall why I approved that change. You're right, calling
set_system does set the GUID back to the default for the filesystem.

You shouldn't even need to call set_system in this case, you already set
it with the call to _new(ext4), and set_flag will leave it set as long
as you are turning a flag on. When you turn a flag off it has to figure
out what to fall back to, so in that case it will call set_system to
return to the default for the filesystem or LINUX_DATA if there is no
filesystem set.

I *think* I was considering the previous behavior a bug, we have a test
that had been disabled for years (t3200 which tests the same thing on
msdos) and these changes made it work again.

I'm not entirely sure what to do about this. It's obviously a change in
behavior, but it's a result of a big improvement in the code that I'd
rather not revert. I should have bumped the library version to indicate
this.

I'm cc'ing this to the parted-devel list to get more input on how to go
forward.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart