golang-k8s-sigs-structured-merge-diff 4.1.2+ds1-2 source package in Ubuntu

Changelog

golang-k8s-sigs-structured-merge-diff (4.1.2+ds1-2) unstable; urgency=medium

  [ Debian Janitor ]
  * Apply multi-arch hints. + golang-k8s-sigs-structured-merge-diff-dev: Add Multi-Arch: foreign.

 -- Jelmer Vernooij <email address hidden>  Sat, 26 Nov 2022 13:02:41 +0000

Upload details

Uploaded by:
Debian Go Packaging Team
Uploaded to:
Sid
Original maintainer:
Debian Go Packaging Team
Architectures:
all
Section:
golang
Urgency:
Medium Urgency

See full publishing history Publishing

Series Pocket Published Component Section
Mantic release universe misc
Lunar release universe misc

Builds

Lunar: [FULLYBUILT] amd64

Downloads

File Size SHA-256 Checksum
golang-k8s-sigs-structured-merge-diff_4.1.2+ds1-2.dsc 2.4 KiB 3199631e2f9d213ade4b05de466a8ccf9e192e62d9154772ee0b8966018f0e64
golang-k8s-sigs-structured-merge-diff_4.1.2+ds1.orig.tar.xz 119.5 KiB 6c72143cdb64524fa0c032c289a4dcc3b2f441926cabd3480c2ebd3b43fee813
golang-k8s-sigs-structured-merge-diff_4.1.2+ds1-2.debian.tar.xz 3.0 KiB 960e40daeebcf4ffc6f1e2d99c991e8d92e03b2756822a4076dd734a626eb9c8

Available diffs

No changes file available.

Binary packages built by this source

golang-k8s-sigs-structured-merge-diff-dev: implementation for "server-side apply" (library)

 What is the apply operation?
 .
 It models resources in a control plane as having multiple
 "managers". Each manager is typically trying to manage only one
 aspect of a resource. The goal is to make it easy for disparate
 managers to make the changes they need without messing up the things
 that other managers are doing. In this system, both humans and
 machines (aka "controllers") act as managers.
 .
 To do this, it explicitly tracks (using the fieldset data structure)
 which fields each manager is currently managing.
 .
 Now, there are two basic mechanisms by which one modifies an object.
 .
 PUT/PATCH: This is a write command that says: "Make the object look
 EXACTLY like X".
 .
 APPLY: This is a write command that says: "The fields I manage should
 now look exactly like this (but I don't care about other fields)".
 .
 For PUT/PATCH, it deduces which fields will be managed based on what
 is changing. For APPLY, the user is explicitly stating which fields
 they wish to manage (and therefore requesting deletion of any fields
 that they used to manage but stop mentioning).
 .
 Any time a manager begins managing some new field, that field is removed
 from all other managers. If the manager is using the APPLY command, it
 calls these conflicts, and will not proceed unless the user passes the
 "force" option. This prevents accidentally setting fields which some
 other entity is managing.
 .
 PUT/PATCH always "force". They are mostly used by automated systems,
 which won't do anything productive with a new error type.