Hi Fabian, Quoting Fabian Grünbichler (2023-07-12 19:53:08) > On Tue, Jul 11, 2023 at 01:47:53PM +0200, Jonas Smedegaard wrote: > > rust-log 0.4.19-2 apparently removed upstream feature kv_unstable > > (according to inspection of source of that packaging release - > > related changelog entry does not mention that feature). > > > > This change to upstream API was done without coordination with > > reverse dependencies, and breaks at least librust-async-std-dev > > and its 17 reverse dependencies. > > > > Yes, I am aware that changelog entry indicates this being a temporary > > change, pending packages lingering in NEW queue. Please don't release > > breaking changes without prior coordination with reverse dependencies > > (e.g. the changes that cause bug#1040702), and in cases that is not > > possible (e.g. when accidentally ending at bug#1040702) then please > > notify reverse dependencies e.g. using a bugreport with tag "affects". > > This was by mistake, and not on purpose.
Understood. > 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. But until succesfully circumvented in reverse dependencies, I would (obviously) appareciate if you could continue to keep that feature alive. Please when you patch away features, document why more clearly than within the changelog. I (hopefully consistently, but might myself have missed some) mention it in debian/TODO which gets included in binary packages as well. > In a slightly related note, there will be two upcoming transitions that > will affect (rust) packages of yours (bindgen to 0.65, and toml to 0.7) > as part of updating rust-cargo to 0.70. Would you appreciate bugs with > patches filed before the transition starts, or do you want to handle > those on your own? You can find some details in the (WIP) tracking > issue[2]. bindgen should be pretty straight-forward, for toml we will > likely opt for a period of semver-suffixing since the versions do have > breaking changes where breakage is not detected at compile time. Thanks for the warning (and for doing those upgrades - much appreciated!). Yes, please generally file bugreports ahead of time against (or "affects" tags towards) reverse dependencies - it is not only for me, but also for public transparency that we promise as part of our "we won't hide problems" attitude in Debian. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
