You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ziti-edge-tunnel (ZET) is vended as a DEB package for each of the most recent Ubuntu LTS releases. The Ubuntu installer shell script chooses the best LTS release codename in case the system isn't running an LTS release.
How should we handle the situation where ziti-edge-tunnel was previously installed and the codename changes such that the appropriate LTS release also changes?
An example of this scenario is when an OS is upgraded from groovy to lunar because the mapped LTS releases for those vintages are focal and jammy, respectively.
According this AskUbuntu answer, it may be widely accepted that 3rd party sources are reviewed for codename changes during an OS upgrade. This matches my intuition that the system administrator will prefer to audit their sources, not trust a metapackage to manage them automatically. A quick search leads me to think that 3rd party apt sources are not automatically disabled during an OS upgrade, and so it seems to be solely up to the system admin to audit sources at that time.
Alternatives to a repo management (meta?)package may include collapsing the distro differences with install or upgrade scripts built in to a single package for all distros per architecture. In that possible future, all OSs that use DEB packages subscribe to the same apt source (no variation per distro).
The text was updated successfully, but these errors were encountered:
This looks like the right approach, and it needs to manage the repo metadata signing pubkey too. That way, we can rotate the key if needed, and because the pubkey was first published with an expiry June 2024, so we need to get the mgmt package out there ASAP to avoid signature errors down the road.
qrkourier
changed the title
vend a DEB repo management package?
vend a generic repo management package?
Mar 20, 2024
ziti-edge-tunnel
(ZET) is vended as a DEB package for each of the most recent Ubuntu LTS releases. The Ubuntu installer shell script chooses the best LTS release codename in case the system isn't running an LTS release.How should we handle the situation where
ziti-edge-tunnel
was previously installed and the codename changes such that the appropriate LTS release also changes?An example of this scenario is when an OS is upgraded from
groovy
tolunar
because the mapped LTS releases for those vintages arefocal
andjammy
, respectively.According this AskUbuntu answer, it may be widely accepted that 3rd party sources are reviewed for codename changes during an OS upgrade. This matches my intuition that the system administrator will prefer to audit their sources, not trust a metapackage to manage them automatically. A quick search leads me to think that 3rd party apt sources are not automatically disabled during an OS upgrade, and so it seems to be solely up to the system admin to audit sources at that time.
Alternatives to a repo management (meta?)package may include collapsing the distro differences with install or upgrade scripts built in to a single package for all distros per architecture. In that possible future, all OSs that use DEB packages subscribe to the same
apt
source (no variation per distro).The text was updated successfully, but these errors were encountered: