On Mon, Apr 14, 2025, at 12:54 AM, Jonas Smedegaard wrote: > Quoting Fabian Grünbichler (2025-04-12 16:13:42) >> On Mon, Apr 7, 2025, at 9:37 AM, Jonas Smedegaard wrote: >> > Quoting Jonas Smedegaard (2025-04-07 09:29:04) >> > Possibly the cause of this issue is that the Debian packaging carries a >> > patch that mangles upstream default feature to enforce a specific >> > crypto engine: That might very well wreak havoc for any reverse >> > dependency expecting to be able to, well, *choose* a crypto engine. >> > >> > Just a guess, and since the patch is totally undocumented - i.e. lacks >> > DEP-3 patch headers and is not mentioned in changelog, I give up >> > speculating any further... >> >> I looked at this a bit during the BSP here - could you give more context >> about how you trigger the failure? AFAICT you can just disable default >> features on your side and pick the runtime+crypto-backend combination >> of your choice and things should work as expected - the latter you >> have to do anyway, since neither no features enabled, nor all features >> enabled would work. >> >> the default feature is the easiest way to get some build/autopkgtest >> coverage, we could of course also skip tests at build time altogether >> instead, or add a ton of manual overrides, but I am not sure it is worth >> it.. > > Upstream default for the crate secret-service is to not decide on a > crypto engine. > > Debian packaging enforces a crypto engine, which means that downstream > reverse dependencies of secret-service needs to be patched to match > that fork of the upstream API.
it doesn't enforce a crypto engine (that would mean hard-coding one and patching out the rest), it defaults to one (which is trivial to undo in any reverse dependency if desired, at the same place that makes the crypto provider selection in the first place). > I fail to understand how that is "the easiest way". it requires the least overriding on our end when packaging. we could go down a more complicated route involving more overrides that have to be kept in sync with upstream, but so far I haven't seen an argument that would warrant it.
