[pve-devel] [PATCH pmg-api] handle pve-kernel -> proxmox-kernel rename

[Fabian Grünbichler]

On July 25, 2023 5:06 pm, Thomas Lamprecht wrote:
> On 18/07/2023 11:10, Fabian Grünbichler wrote:
> 
>> diff --git a/src/PMG/CLI/pmg7to8.pm b/src/PMG/CLI/pmg7to8.pm
>> index 85e9f16..8cccde1 100644
>> --- a/src/PMG/CLI/pmg7to8.pm
>> +++ b/src/PMG/CLI/pmg7to8.pm
>> @@ -193,7 +193,7 @@ sub check_pmg_packages {
>>  	}
>>  
>>  	# FIXME: better differentiate between 6.2 from bullseye or bookworm
>> -	my ($krunning, $kinstalled) = (qr/6\.(?:2\.(?:[2-9]\d+|1[6-8]|1\d\d+)|5)[^~]*$/, 'pve-kernel-6.2');
>> +	my ($krunning, $kinstalled) = (qr/6\.(?:2\.(?:[2-9]\d+|1[6-8]|1\d\d+)|5)[^~]*$/, 'proxmox-kernel-6.2');
> 
> this looses backwards compat though?
> 
> Makes update harder as we need to coordinate closely moving packages around..
> Same for PBS and PVE.

this ('$kinstalled') is the package that should be installed after the
upgrade has happened (for the non-upgraded case, we check for
pve-kernel-5.15). technically it means that yes, we should move
proxmox-mailgateway (which transitively depends on the renamed kernel
pacakges) and pmg-api at the same time through the repos.

that's why I noted that

> the proxmox-mailgateway meta package could get a versioned dep on
> pmg-api with this change, but it's not strictly required.

in this patch (and the other similar ones for their respective meta
package).

the only thing that breaks if we don't do that is this check here
complaining if
- pmg-api moved faster than the renamed kernel packages (or for some
  reason, a partial upgrade was done)
- *and* the running kernel version is an unexpected one (upgraded, but not
  yet rebooted, or some other non-standard setup)

it still rightfully complains, but with the wrong message..