[Pkg-rust-maintainers] Bug#1068008: rustc: Please package rust 1.75 or higher

[Fabian Grünbichler]

On Tue, Apr 23, 2024 at 06:32:04AM +0900, Mike Hommey wrote:
> On Mon, Apr 22, 2024 at 10:24:09PM +0200, Fabian Grünbichler wrote:
> > Hi Wesley, Yaroslav, Carsten and Mike,
> 
> Hi Fabian,
> 
> Let me start by thanking you for the work going into packaging rustc.
> 
> > while we try to keep rustc somewhat current in sid, this is not always
> > possible in a timely manner.
> 
> rustc 1.70 was released on June 1 and made it to unstable in September.
> We're now 7 months later.

yeah, most of the delay there was a result of bookworm and the freeze
(rustc as part of the toolchain set gets frozen early, and we found out
the hard way this time around that if we prepare release in experimental
we still have to go through bin-NEW - and of course, we've also had our
hands full with other getting-rustc-stuff-ready-for-bookworm things at
that time).

> At the time rustc 1.70 was released, unstable had... 1.63, which was
> released close to a year prior, at which time unstable had... 1.59.

see above. 4-5 versions is  not unheard of. when 1.70 was released, we
had 1.67 in experimental, for example.

> "rustc somewhat current in sid" might have been true in the past, but
> that has unfortunately not been the case for at least two years, now.
> I'm not discounting your work, merely stating the hard truth.

we might have different definitions of "somewhat current" :)

most stable projects are okay with about 6 months lag, which is about 4
rustc releases.  and that's not taking into account that we don't always
package the latest release the moment it's out of the door for things
depending on rustc/cargo either.

I do aim for less, of course, but it doesn't always work out as
intended.

> The sad part is, as you noted, the more outdated the version in unstable
> is, the worse it gets to update it...

well, the amount of work it takes is about the same, but the wait is of
course longer if the lag is bigger, yes.

> > I am sorry to say that I don't expect us to be caught up with 1.75
> > (which is 5 trips through bin-NEW, one of them bigger than usual cause
> > of the merge, and probably 20-40h of rebasing and testing work on my
> > end) until at least the end of May :( I will make sure to include the
> > requirements of thunderbird/firefox if things get stuck in NEW for too
> > long.
> 
> And by end of May, we'll be close to the upstream release of rustc 1.79...
> 
> Is there anything we can do to make things better? Presumably, the
> src:cargo merge should help here, at least a little (because cargo being
> outdated has also been another source of recurring problems).

well, I'd be happy to share the workload ;)

but it requires a substantial commitment - reviewing an MR for an
update is not that much less work than doing it myself, since the
package is quite complex, and quite important. I can do that a few
times, but if it's not for somebody who wants to comaintain long-term
it's probably time better spent improving the tooling or specific bugs.

I do hope to at least get rid of two bottle necks soon that have
affected updates in the past
- the split between cargo and rustc, with cargo having its own set of
  problems that made updating harder, which should be mostly eliminated
  with the merge
- me just being a DM, with additional delays introduced by waiting for
  somebody else from the team somewhat familiar with the packages
  uploading to bin-NEW (I am a DD now, but my key/account is not active
  yet)

> At least for firefox, I managed to relax the rustc requirement back to
> 1.70, so the urgency is slightly less severe at least for that package,
> for now.

that's good to know, I'll still try to get the lag reduced ASAP!