Re: [pdm-devel] [PATCH datacenter-manager/proxmox{, -yew-comp} 00/18] remote update view: include product version and repository status

From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Datacenter Manager development discussion
	<pdm-devel@lists.proxmox.com>,
	Lukas Wagner <l.wagner@proxmox.com>
Subject: Re: [pdm-devel] [PATCH datacenter-manager/proxmox{, -yew-comp} 00/18] remote update view: include product version and repository status
Date: Mon, 1 Dec 2025 03:35:06 +0100	[thread overview]
Message-ID: <316790e0-fd73-4a1c-9ab7-6c0dd008f49c@proxmox.com> (raw)
In-Reply-To: <20251127104447.162951-1-l.wagner@proxmox.com>

Seems all good in general, but sadly it gets broken by having any PVE 8 remote,
but really not your fault, our old APTRepositoryHandle enum friend – the gift
that keeps giving - is just at it again...

I.e., we always return the standard repos when gettign the current repos (that
probably should be split out though), and there we also have the ceph repos.
As we do not use a struct with the infos like product (ceph, pbs, pve, ...)
version or type (enterprise, test, ..) separately, but mixed into one enum,
we have to make that enum specific to each version to match the correct set
of repos we provide (mainly affected by Ceph).
So that enum is basically always incompatible with other major versions and
also likely within the same major version, e.g. if a new ceph releaase was
added.

Now, I though I could stop-gap-band-aid fix this using Stefans/Wolfgangs
UnknownEnumVarian(FixedString) approach, and I actually rolled that out,
but our FixedString only allows for 23 characters (+ 1 byte for len tracking
gives a nice even 24). Well, 23 chars? That should be enough for everyone?
Nope, "ceph-quincy-no-subscription" has 27 and is tucked in every repo request,
even if it's not configured. So even that did not work out. I now changed the
FixedString to 31 chars + 1 len tracking u8 as Real Stop Gap™, mainly because
we wanted to go for that limit initially anyway. Well, enums will be a bit
more bloated now, but until we actually fix the root of our pain here that's
an OK trade-off.

And I'm a bit torn in fixing that root still now already, actually pushed a
rebased wip branch of apt-api-types to my staff repo with my initial draft,
but it's not trivial to get right, so shooting from the hips might cause us
even more pain down the line; so let's again postpone it, but really fix
it until next release (any takers x)?)

_______________________________________________
pdm-devel mailing list
pdm-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel