On Mon, 2026-08-10 at 10:07 +0200, Andrew Lee wrote: > But I worry this creates long-term technical debt and splits the > archive between two competing build systems. Having two parallel build > methods in unstable makes debugging reverse dependencies more > difficult and confusing. Also, since dh-golang still needs a lot work > for module-aware builds, adding more hacks to support both systems at > the same time will be hard to maintain when there is new issue > addressed. > > I suggest we focus all our energy only on polishing dh-golang for > module-aware builds right now, rather than spending time adding > fallback options to the tooling. > > Mathias already mentioned he expected to upload dh-golang to unstable > within this month. What do you think?
On Mon, 2026-08-10 at 10:27 +0200, Simon Josefsson wrote:
> What I feared was that we delay uploading the new dh-golang to unstable
> almost indefinitely because we haven't finished the experimental
> uploads, and this becomes a chicken and egg situation...
As Andrew mentioned, I'm hoping we'll be able to upload dh-golang to
unstable by the end of the month. This will kick off the official
transition, for which there's already a bug (#1137232), but we'll want
to coordinate with the Release Team.
The minimum baseline is that no existing issues in dh-golang are
known, and that a majority of Go packages build properly, either
directly in unstable or with modifications in experimental. I expect
there will still be some Go packages that need updates to build
properly, but we shouldn't wait until 100% of them are updated -- this
could be a very long tail that I personally don't think we should let
impede our efforts to get modern Go builds available in Debian.
In the same line of thought, I don't think we should try to maintain
support for the current ("old") way of building. At best this will push
out the timeline for when Debian is fully transitioned to modern Go
builds, and at worst adds complexity and allows packagers to continue
being stuck in the past.
The upload of dh-golang from experimental to unstable will be a "flag
day" for Debian, and I think that's good. We're still plenty early in
the forky development cycle that I don't think we risk releasing with a
broken Go build ecosystem and will have plenty of time to address any
remaining issues that shake out. Additionally, if there are Go packages
that start failing to build and no one addresses them, there will be
time for FTBFS bugs to be filed, and then the autorm process to prune
them from testing before the forky freezes start. This will mean that
we should be able to ensure all Go packages in forky are built using
the modern approach.
Mathias
signature.asc
Description: This is a digitally signed message part
