The type is
typedef struct {
const gchar *name;
SecretSchemaFlags flags;
SecretSchemaAttribute attributes[32];
/* <private> */
gint reserved;
gpointer reserved1;
gpointer reserved2;
gpointer reserved3;
gpointer reserved4;
gpointer reserved5;
gpointer reserved6;
gpointer reserved7;
} SecretSchema;
so the current object we give it is 8 pointers too short
It's incredibly lucky that libsecret, at this time,
only uses reserved, and not in any of the functions we call
Previously, LibSecretCredential was created multiple times and with it
libsecret was loaded and unloaded multiple times, leading to issues
where calls could run indefinitely due to glib not properly cleaning up.
Now, LibSecretCredential is stored in a OnceLock, ensuring it is only
created once, preventing unnecessary unload/reload cycles of libsecret.
This is to bring us into conformance with the [Rust crate ownership
policy](https://forge.rust-lang.org/policies/crate-ownership.html).
Items of note
- `cargo-credential-1password` is declared as Experimental as it is
intended for the community but I was unsure if we wanted to commit to
full support for it. In my mind, the ideal thing to do would be to
expatriate this to 1password.
- `home` is declared as Internal despite its wide use within the
ecosystem.
- `cargo-credential` is declared as Intentional as its an API intended
for the wider ecosystem and I didn't see a reason to declare it
experimental.
- `cargo-platform`, `cargo-util-schemas`, and `crates-io` are declared
as Intentional as they are both used internally and intended for
others to use for logic that integrates with cargo/registries.
I wondered about these being Experimental or Internal instead.
The library name `libsecret-1.so` is only found in `-dev` or `-devel`
packages on many distros, and it's usually only a symlink. For example,
this is what I have on Fedora:
/usr/lib64/libsecret-1.so -> libsecret-1.so.0
/usr/lib64/libsecret-1.so.0 -> libsecret-1.so.0.0.0
/usr/lib64/libsecret-1.so.0.0.0
$ rpm -qf /usr/lib64/libsecret*
libsecret-devel-0.21.4-2.fc40.x86_64
libsecret-0.21.4-2.fc40.x86_64
libsecret-0.21.4-2.fc40.x86_64
The middle `libsecret-1.so.0` filename matches the actual `SONAME` in
the library, which you can see with `readelf -d`, and this is what
programs built directly against this library will use. It's a better
choice for dynamic loaders too, so devel packages aren't needed.
We likely don't want to release these packages every 6 months just for
an MSRV bump.
By moving the MSRV out of the package, `cargo bump-check` will ignore
the MSRV bump.
Inspired by #13266
This will require a version bump every release but over-releasing these
packages is likely a lot better than over-releasing the N-3 packages,
which we won't have to do anymore after this.
My hope is the `auto` value will be approved and stabilized and then we
won't have to over-release anymore.
