docker.io is a very demanding package to maintain.
Maintaining Docker is a big commitment and more maintainers are needed.

Any help is appreciated; most of the effort is likely to be with Docker's
dependency tree.
---

Continuous effort - not strength or intelligence - is the key to unlocking
our potential.
        -- Winston Churchill

Hola ,
I am Manas Kashyap an active Debian contributor and i have knowledge about
Debian packaging and i would like to maintain the package .
Thanking you
Manas kashyap <http://manas-kashyap.github.io>

Thank you. Please speak with Arnaud who is de-facto maintainer of this
package.

Arnaud, please promote yourself to Maintainer. I'll stay around as Uploader
for some time but probably won't be doing any significant work.
Please feel free to upgrade this bug report to RFA if you wish.

---

It is a mistake to try to look too far ahead. The chain of destiny can only
be grasped one link at a time.
        -- Winston Churchill

Will do, thanks!
I think he is connected to this Mailing thread .

  Hi Manas,

you're very welcome to join the Docker packaging effort!

At the very moment, what you can do to get started is to get familiar
with the package, git clone from salsa, and build it. Make your setup
ready, whatever your tools you use to build the package (schroot,
pbuilder, containers, none?, etc...). If you have issues with that
please get in touch.

Regarding Buster release, we're almost there, there's nothing you can do.

Once Buster is out, there will be plenty of work, mainly bumping the
package to latest upstream versions. I also want to try to unbundle
containerd from the docker package, I've seen that Shengjing Zhu
uploaded an up-to-date version to experimental. But it depends on how
much containerd reduced their dependency on docker, and how much docker
uses release versions of containerd rather than snapshot.

Cheers,

  Arnaud

Awesome, thanks!
So , till the package is in Buster , i will clone it and try to build it
Thank you.

On Mon, Jun 10, 2019 at 10:33 AM Arnaud Rebillout < arnaud.rebillout@collabora.com> wrote:

This may be very risky to do so one have to have a good justification what
those risks are taken for.

It has been attempted in the past with disastrous results. Containerd is used
by Docker (exclusively?) and with very specific vendoring. With current
upstream culture of incompetence in regards to versioning, another attempt to
ship containerd separately is likely to fail. Unbundling containerd should be
considered very very carefully with full understanding of why burning effort
for the attempt.

---

Do your duty as you see it, and damn the consequences.
        -- George S. Patton

AFAIU there's two issues:

1. the fact that docker uses snaphots of containerd.

2. the fact that both docker and containerd vendor each other, leading
to unbreakable circular dependencies.

For issue 1, I would have a the docker releases accross the last year,
and see what version of containerd they use. If it happens that they
consistently use releases of containerd rather than snapshots, then
maybe we can consider that issue 1 is gone (but it's true that they're
no warranty that they won't go back to using snapshots later down the
road....)

For issue 2, I would try to have a look at what they vendor from docker,
once again over a one year time span, and try to assess it they're doing
any progress un-bundling docker parts from containerd, or not. I've seen
in Shengjing Zhu's containerd package that there is still some vendoring
of docker parts, so I don't think it's solved yet, but maybe it's on the
way.

Even if these two points are solved, it's true that there's a risk that
it comes back, even more both projects have more or less the same
upstream. I'm not really aware of who develop what, and if both projects
are really developed separately, or by the same group of people.

Hello,

I am Badrikesh Prusty and wanted to help upgrading the docker.io package.

With the Debian packaging knowledge, I tried packaging docker.io v26.0.1 and its dependency components such as containerd, runc, etc.

When we tried installing this on Debian 11 and 12, docker and its components seems to work normally.

Kindly, provide further information on how the docker packages are validated, before it is pushed to apt repository.


Thanks & Regards,
Badrikesh Prusty

Hi,


I'm Christian Lehnert and I use Docker daily as a software developer and system administrator. Building worked for me on Debian 12 and 13.


If you need any help with anything, I'm happy to help. I use Docker every day so working Docker is important for me. I'm happy to get into the basics of the project if you want and I'm happy for any information I need.


Best regards,

Christian Lehnert

Hi,

I've been doing Debian LTS security backport work lately (caddy,
cjose, git-lfs, libgit2 - real MRs/patches, not just talk:
https://salsa.debian.org/go-team/packages/caddy/-/merge_requests/3
is a recent example, 8 CVEs backported to bookworm) and I'd like to
put some of that toward docker.io, given the RFH has been open a
while.

Rather than a generic offer, I'd rather ask directly: is there a
specific slice of the CVE backlog or the dependency tree that's
actually the bottleneck right now, or a particular kind of help
that's more useful than others? Happy to start small and build up
context rather than assuming I know what's needed.

Ivo

What I personally struggle is with preparing the next stable updates.

Do you think this is something you could start preparing
in your salsa fork?

Definitely - happy to take a piece of that on.

Checked the security tracker first: bookworm currently has 13 open
CVEs (CVE-2026-42306, -41568, -41567, -34040, -33997, -33748, -33747,
and a few older ones back to 2024-24557), trixie's already clean once
the +deb13u1 in proposed-updates migrates.

I also found wip/rt/security on the Salsa repo - 268 commits ahead of
debian/bookworm, so clearly a real, substantial effort, not something
I should just barge into blind. Before I start: is that branch meant
to become the actual next bookworm upload (in which case I'd rather
help push specific pieces of it forward than duplicate work), or would
a smaller, CVE-only patch set on top of the current bookworm as it
ships now be more useful and shippable sooner - closer to how I've
been doing the other LTS backports this week?

Either way works for me - just want to point effort where it actually
helps rather than guess.

Ivo