this prevents us from using it under certain conditions and it's
actually not necessary, so drop them
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
* Updatable is now named UpdaterType
* UPDATER_IS_OPTION is now assumed to always be true
While an updater can be a non-optional struct, being an
updater, all its fields are also Updaters, so after
expanding all levels of nesting, the resulting list of
fields can only contain optional values.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
This way we can assign `API_SCHEMA` constants to `Option`
types.
Here's why:
The api-macro generated code usese `T::API_SCHEMA` when
building ObjectSchemas.
For Updaters we replace `T` with
`<T as Updatable>::Updater`
This means for "simple" wrappers like our `Authid` or
`Userid`, the ObjectSchema will try to refer to
`<Authid as Updatable>::Updater::API_SCHEMA`
which resolves to:
`Option<Authid>::API_SCHEMA`
which does not exist, for which we cannot add a normal
`impl` block to add the schema variable, since `Option` is
not "ours".
But we now have a blanket implementation of `ApiType` for
`Option<T> where T: ApiType` which just points to the
original `T::API_SCHEMA`.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
#[api]
struct Foo {
field: Bar,
}
does not require the use of
#[api(
properties: {
field: {
type: Bar,
},
},
)]
anymore
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
which allows to get rid of an possible error with check_suites, and
easily detect unexpected values with get_current_release_codename.
The check_repos function needs to be adapted, since the type does
not include suite names like oldstable,experimental,etc.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
by exchanging loops in the check_suites function, which was the only
user. Exchanging loops also helps for introducing a type for Debian condenames.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Like that, a potential error is further up the stack, and it's more
consistent with what the standard_repository functions do.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
use the first appearance of '-' or '/' to detect the variant instead
of keeping a list of possible variants, which would need to include
things like "-proposed-updates-debug".
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Require that the suite matches too when detecting standard
repositories, since no or invalid updates will be obtained when the
suite is wrong. Thus, it should not be considered to be the same
repository.
Add the parameter for get_standard_repository too, so that the two
related calls have more similar parameters, and the detection of the
current release code name can be done once in the caller once.
This also will fix an issue with the front-end, where adding a
standard repository would end up just enabling an already present
repository with the wrong suite.
Reported-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Some file systems don't support renameat2's RENAME_NOREPLACE
flag (eg. ZFS), at the some time, some other file systems
don't support hardlinks via link (eg. vfat, cifs), so we now
try both: first the rename (since it's more efficient), then
link+unlink for the rest.
If both fail, the file system is simply not supported for
our purposes anyway...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
we are not really compatible with pbs1, needs a stable-1 branch if we
need to backport something
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
