* 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,
Arnaud
