to reduce the creep of optional dependencies being exposed as features.
this requires cargo 0.63 (and debcargo built against at least that
version), but greatly reduces the number of binary packages and provides
generated, while still allowing sensible selection of optional
dependencies via the explicit feature meant for pulling them in.
diff stat for running `make deb` after this change:
proxmox-http/debian/control | 226 ++++--------------------------------
proxmox-router/debian/control | 74 +-----------
proxmox-schema/debian/control | 53 ++-------
proxmox-subscription/debian/control | 17 +--
proxmox-sys/debian/control | 51 +++-----
proxmox-tfa/debian/control | 110 ++----------------
6 files changed, 72 insertions(+), 459 deletions(-)
the 'dep:' prefix marks something on the RHS inside the features section
as dependency, it's only allowed if the string after it is an optional
dependency an no explicit feature of the same name exists. if all
pointers to the optional dependency in the features section are marked
as such, the optional dependency itself will not be exposed as a feature
(either on the cargo or debian/control level).
the '?' suffix marks dependencies as "weak", which only enables the
optional dependency + its feature(s) if the optional dependency itself
is also enabled. it has no effect on d/control since such a relationship
is not encodable in Debian package relations, but it does affect cargo
dependency resolution and allows skipping the build of unneeded optional
dependencies in some cases.
with no packages/crates depending on the no longer exposed automatically
generated features/packages, so these are safe to remove even though
it's technically a breaking change.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
This would allow the following components:
* all in one : &["system/network"]
* mixed: &["system/network", "dns"]
* with templates: &["datastore/{store}"]
* with the value of template being a path, e,g, with ns = "foo/bar":
&["/datastore/{store}/{ns}"]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
these should not be required as the use cases should all be
covered by the non-reference impls
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
they should behave like their normal variants, but return a
`Box<dyn SerializableReturn + Send>` instead of a value. This is useful
since we do not have to generate the `Value` in-memory, but can
stream the serialization to the client.
We cannot simply use a `Box<dyn serde::Serialize>`, because that trait
is not object-safe and thus cannot be used as a trait-object.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
this will be useful as a generic return type for api calls which
must implement Serialize.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
will break usage of the `Result::Ok()' with anyhow 1.0.49+ as that
added a new Ok helper, so a glob-import would make that shadow the
core one.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
