On Wed, May 20, 2026 at 12:24 AM Pirate Praveen
<[email protected]> wrote:
> Thanks, but I don't think a package not in testing will be accepted into
> backports.
Understood. But you don't need that in testing and backports while
only use that package locally to bootstrap a -cloud package first. And
then build an update -cloud package to newer upstream version that
doesn't depends on it.
> Can there be an exception for a temporary bootstrapping package? Or can
I think you can do both locally with your
pbuilder/cowbuilder/sbuild...for bootstrapping packages.
> I add these as vendor inside debian temporarily? I can remove them after
> the latest versions are accepted.
You are allowed to do whatever locally for bootstraping even for cross
building. Just ensure in the end, you rebuild the package cleanly and
tested the clean package with ratt. And then upload package
cleanly(ensure the source package may builds on buildd) as well.
----
To Go Team, Backports Team and Security Team,
This is a reminder that the current Go ecosystem is Debian makes
responding to Security fix in LTS and Backports exceptionally
difficult. I have fixed some CVEs in Sid and Forky recently. I known
how difficutlts are there for fixing the same in backports.
In Debian, we currently builds Go packages with legacy
`GO111MODULE=off` flag creates many issues including security issues
across Trixie, Forky and Sid. (If you don't know why, watch my talk in
mini DebConf Hamburg.) We need re-implementation and re-design how the
Go packages builds in Debian.
I believe we need to address the following key areas:
1. Migrating to Module-Aware Builds
We must stop working acround broken Go binaries and skip/disable tests
caused by the legacy `GO111MODULE=off`, and switch to Module-Aware
Builds.
* The GOPROXY Approach:
- There is an existing Policy Merge Request on Salsa suggesting use
GOPROXY method but doesn't provide any info how to make it works.
After I checked, a true GOPROXY required upstream .zip files and
go.mod for each module. And we also need to setup a private GOPROXY in
Debian infrastructure for buildd to use which may not be the most
practical path forward.
* The Go Workspace (go.work) Approach:
- As a Proof of Concept, I tested in bash script that use Go
Workspace(go.work) method to map go.mod requires directly to to local
installed Debian packages paths. This works perfectly when build
dependencies provide proper go.mod files.
- However, integrate this into dh-golang, would require updating and
around 90% of golang packages in Debian of our exist golang source
packages. (Some packages provided broken or mismatch go.mod file and
some package is out of date that doesn't provide a go.mod file. And
some package has dead or legacy upstream has no go.mod file exist.)
2. Enhance Security Tracking
- Upstream Go security fixes usually just a single-line version bump
in go.mod file for it's dependencies.
- Because Debian currently buils Go packages without strictly
tracking these upstream module versions, upstream security advisories
do not accurately reflect the state of our packages in Debian.
- In practice, many Go packages in Debian behave like un-trackable
upstream forks. A lot of hacks that changed the upstream module
versions to force the package builds with skipped/disabled tests and
untested broken binaries.
3. Transitioning to Binary-Only Shipping (The `icingadb` Model)
- To resolve the dependency hell that blocks backports and security
responses (such as circlar build-dependencies with -google-cloud/api
packages, deal with build-dependencies not exist in Debian anymore),
we should consider moving forward to a binary-only model in Debian.
- Use `GO111MODULE=on` method by default.
- Allow app/binary packages to ship their sepcific upstream security
tested/tracked dependencies.
This ensures the package can be easily backported to older stable,
oldstable, oldoldstable distributions when we received upstream
security advisories.
- Get rid of out of date or obsolated Go related -dev packages in
Debian. This would reduce a lot of space in our archive and free up a
lot of maintainer resources.
- Shift maintainer's focus into the quality of the Go binary/app
packages we ship. No more incompatible competitions between -dev
pacakges amond us, and also eliminating bootstrap and backport
burdens.
To resolve these challenges, we should schedule a dedicate discussion
on the Go Ecosystem. A BoF session at DebConf26 would be an idel place
in my mind. But I welcome any suggestions on how we can kickstart this
transition sooner.
Best regards,
--
-Andrew
