Hi, On Thu, 12 Feb 2026 09:59:58 +0700 Arnaud Rebillout <[email protected]> wrote: > * Reinhard Tartler <[email protected]> [2025-12-03 06:51]: > >- Bump Trixie to 1.2.8/1.3.3 (i.e., introduce new source "runc-app > that produces the `runc` binary", like Ubuntu). > > Indeed, Ubuntu ships runc 1.3.3 in 22.04 LTS, 24.04 LTS and newer. > However their runc source package embeds the complete vendor tree, and > their Build-Depends are minimal. That's why it's fairly easy to rebuild > this package for older Ubuntu releases. > > However in Debian we don't use the vendor tree, so it's a completely > different story. > > I tried to rebuild runc 1.3.3 (currently in Sid) against Debian Trixie. > Result: we need to bump 4 Build-Depends just to meet the constraints. I > didn't go further. > > I tried something more realistic: rebuilding runc 1.2.9 against Trixie. > Result: I had to bump 3 Build-Depends to fix FTBFS (as a shortcut, I > just vendored it). After that, the package is built. I didn't test it. > > At this point I have two concerns: > - I'm not sure it's feasible to upload new versions of the Build- Depends > in Trixie: we risk break builds or regressions in other packages that > use those Build-Depends. > - I'm also interested in supporting Bookworm and Bullseye, and it's > going to be even harder, or downright impossible, to rebuild runc 1.2.9 > aginst those old releases. > > So, in short, and forgive me for stating the obvious: I think the > approach of providing new versions of runc in old versions of Debian can > only work if we use the embedded vendor tree to build it, just like > Ubuntu does. *Do we want to do that* ? > > Another aspect that wasn't discussed yet: src:runc also provides the > library golang-github-opencontainers-runc-dev. I don't know if the CVEs > affect this code and therefore the reverse Build-Depends of it. Reinhard > do you have any idea about that? > > Again, opinions from everyone welcome. Best,
Thanks for working on the backports and for identifying the potential issues — that is very helpful. I had a similar discussion in Ubuntu a few years ago. As you’ve already noticed, we eventually decided that it was preferable to keep updating to newer upstream versions while avoiding breakage of reverse dependencies in the archive. The approach we took was to create separate source packages (e.g. src:runc-app, and similarly for containerd and docker.io) with embedded build dependencies, making them self-contained and not affecting other packages in the archive. Our assessment at the time was that most users rely primarily on the application rather than the provided library. Therefore, ensuring that the application itself receives security fixes — even if not an ideal solution — seemed better than leaving users with known vulnerabilities. The container ecosystem evolves very quickly, which makes backporting particularly time-consuming and, in many cases, still results in breaking changes. I wonder whether Debian would consider a similar approach in the interest of users. We are all aware of the downsides: vendoring build dependencies, introducing larger updates in stable releases, and the general trade-offs involved. However, the alternative is continuing to ship versions with known vulnerabilities. In the long run, users may decide to stop relying on the distribution packages and instead turn to external sources. These are just my thoughts on the matter, and I’m interested in hearing what others think. Lucas Kanashiro.
signature.asc
Description: This is a digitally signed message part
