[Pkg-rust-maintainers] Bug#1040837: Bug#1040837: Bug#1040837: rust-log: breaks API without coordination

[Fabian Grünbichler]

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? ;)