Dear Maintainer,

  Since `docker.io` reached testing, could you please consider backporting it to stable?

  What kind of work would be needed to ease the path to provide such backport?

Regards

No, please... Maintaining Docker is an enormous time sink. I doubt backports
will ever happen and certainly I don't want to be involved.
I'm contemplating orphaning Docker and the only reason I'm still looking
after it is because I think it is strategically important for Debian success.

I don't like Docker. It is very sloppy, bloated, over engineered with
selfish, uncooperative fork-obsessed upstream who refuses to adopt good
versioning practices making our work very difficult.

Recently I've switched all my containers to _rkt_ and I'm very happy about
that.

Whoever needs Docker can install it straight from "testing" since Docker is
statically linked. I can't justify the effort required to maintain the
official backport.

Man time required to backport hundreds of dependency libraries and even more
time to maintain all those, resolve complicated transitions, build/test
failures and tight versioning. Team of several people working full time for
months - that's what it will take.

We are nowhere near the point where it would be safe to backport a monster
package like Docker. First, I'd like to suggest having a real team
maintaining Docker, not just myself. I've already invested too much time into
Docker at the great personal cost and expense of other worthy projects/
packages. I'm not going to stick much longer...

Besides just keeping Docker in testing is a challenge due to build/test
failures routinely exposed by CI. Docker dependency tree is very big and
surface for problems is enormous.

I wholeheartedly recommend using _rkt_ instead and it looks like rkt would be
actually possible to backport.

---

We do our friends no favors by pretending not to notice flaws in their
work, especially when those who are not their friends are bound to notice
these same flaws.
        -- Sam Harris

Hello,

Missatge de Dmitry Smirnov <onlyjob@debian.org> del dia dc., 12 de
set. 2018 a les 2:29:

The whole point to bring back `docker.io` package to Debian was to
provide something usable in stable.

I think so too, please keep up the good work, I am willing to help
(note I collaborated with Arnaud Rebillout) for docker.io to be back
again in Debian.

I agree, but it is key package for Debian and it's users.

I have never used rkt

Hopefully we (Arnaud and I, and maybe other people can join a
docker-team) can help on that.

If we embedded in the package most of the vendoring, would that help
on its future maintenance?
I know that might be a bit controversial however I think it might be
the only way to keep docker.io in the distribution going further
ahead.

Your involvement has been key to give latest push and unblock latest
issues, it was great to find you managed to actually get docker.io
uploaded back to Debian. Thanks for that and all the hard work. I am
also pretty short time, however I'll try to be helpful going forward.

Are you using Gitlab provided CI/CD features to track that? I'd need
to get up to speed with those.

I would need to look at that, however, that's a different package.

Regards,

Thank you for your kind words, Héctor.

It is usable in stable, when installed from "testing" or "unstable".
Usually Golang-compiled static binaries are safe to use in "stable" because
they have very few dependencies.

My point is that backporting all Docker's dependency tree is unjustifiable.
IMHO this time and effort would be better spent to address other outstanding
problems...

Not really... Besides security team would rightfully complain.
Un-vendoring is actually superior because unlike upstream we test the whole
dependency tree. It would be regretful to lose that advantage.

Why would that be? We have dependencies under control now, aren't we?

No, it is usually bugs filed for failures in Debian CI and reproducible build
infrastructure. See recent #907764, #907432. Because of bugs like this
docker.io is regularly targeted for removal from "testing".

---


The more false we destroy the more room there will be for the true.
         -- Robert G. Ingersoll, 1902