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

[Jonas Smedegaard]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20230715/603668ba/attachment-0001.sig>