On Sat, Jul 15, 2023 at 05:07:25PM +0200, Jonas Smedegaard wrote: > Quoting Jonas Smedegaard (2023-07-15 09:55:04) > > Quoting Fabian Grünbichler (2023-07-12 19:53:08) > > > The feature in question is probably not a good candidate for packaging > > > though, given the lack of stability guarantees provided by upstream[0]: > > > > > > > This module is unstable and breaking changes may be made at any time. > > > > See the tracking issue for more details. > > > > > > The referenced tracking issue can be found here[1]. > > > > > > While the required crates (multiple ones from sval-rs/value-bag) are > > > being packaged (mostly done, pending a re-upload to NEW and review > > > there), I wonder whether enabling the feature was not a > > > mistake/premature in the first place. > > > > > > I did a quick test with ratt with the attached diff applied, and except > > > for rust-sequoia-net (which fails for other reasons which are already > > > fixed in experimental and just need a re-upload of the version there to > > > unstable), building at least worked fine. I am not too familiar with > > > either async-std, nor the kv feature of log to say whether this approach > > > would be feasible - I'd be happy to hear your thoughts though! IMHO > > > keeping this unstable aspect out of the archive for the time being would > > > save us all from periodic breakage, with log itself (without the KV > > > feature) being rather widely used. > > > > Makes sense. > > > > I will go through those of the reverse dependencies that I am involved > > in maintaining, to see if th unstable feature can be avoided - and might > > reach out for help if I cannot figure it out on my own. > > While I appreciate your suggested patch for rust-async-std, the main > obstacle to getting rid of the feature seems to not be rust-async-std > but instead rust-kv-log-macro which has 19 reverse dependencies: > > aardvark-dns > rust-ahash > rust-ahash-0.7 > rust-ashpd > rust-async-attributes > rust-async-std > rust-async-std-resolver > rust-async-tar > rust-erbium > rust-femme > rust-flume > rust-futures-timer > rust-oxilangtag > rust-oxiri > rust-rustls > rust-sequoia-net > rust-trust-dns-client > rust-trust-dns-resolver > rust-trust-dns-server > > I am not happy to create Debian-specific patches to somehow replace > rust-kv-log-macro, and even if you were kind enough to initially create > such patches there is still the headache of maintaining them.
ack, that's fair enough, like I said, I am not all too familiar with that part of the ecosystem. IIRC this is the second or third time that it breaks in Debian via sval.. > If the feature in rust-log really is considered too unstable for use in > Debian, then it seems to me that we need to convince upstream projects > to acknowledge that and themselves avoid the feature. probably it would be best to push for stabilization :) do you want to file some issues or should I? ;)